perm filename RLS.MSG[PAR,SYS] blob
sn#551572 filedate 1980-12-22 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00001 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 ENDMK
C⊗;
∂26-Nov-79 0408 Richard H. Gumpertz <Rick.Gumpertz at CMU-10A> Re: Rotate Restriction (complain now or ...)
Date: 8 November 1979 1326-EST (Thursday)
From: Richard H. Gumpertz <Rick.Gumpertz at CMU-10A>
Subject: Re: Rotate Restriction (complain now or ...)
To: Mike Farmwald <PMF at SU-AI>
CC: S1Arch at SU-AI
Message-ID: <08Nov79 132646 RG02@CMU-10A>
In-Reply-To: Mike Farmwald's message of 27 Oct 79 23:26-EST
I think you should make the upper limit on ROTATE be <=, i.e. allow
rotate to be 0 <= RCNT <= {9,18,36,72}. This allows one to do be a bit
more flexible without having to do the MOD operation. In general, I
dislike things which don't let me get at the end points. In this case,
I might want to right-rotate by a count I know to be already between 0
and 71. I ought to be able to use 72-N as the argument without having
to use a MOD operation. Is it hard to add this?
Rick
P.S. I agree with Curt that out-of-bounds arguments should TRAP!
Mysterious undefined behavior is NEVER desirable to the reasonable
programmer.
∂26-Nov-79 1806 ARK S-1 Meeting Notice
To: S1 at SU-AI
CC: pickering at SUMEX-AIM
SAIL is now back on the ARPANET, so apologies if you get this notice twice.
The next S-1 meeting will be on Wednesday, 28 November at 1:15pm in MJH301.
Arthur
∂27-Nov-79 0754 ''Guy L. Steele, Jr.'' <GLS at MIT-AI> Re: Rotate Restriction (complain now or ...)
Date: 27 November 1979 10:21-EST
From: "Guy L. Steele, Jr." <GLS at MIT-AI>
Subject: Re: Rotate Restriction (complain now or ...)
To: PMF at SU-AI, Rick.Gumpertz at CMU-10A
cc: S1Arch at SU-AI
I agree that a rotation by the size of the word should be permissible.
Certainly a shift by that amount should be permitted...
∂27-Nov-79 2038 PEG Progress Report
To: "@SOPA[DIS,S1]" at SU-AI, "#PROG.MSG[LOG,S1]" at SU-AI
Last two weeks:
I was not able to put in a lot of time due to a lot of classwork, but
I made a minor amount of progress on both the Intro to the S-1 document
and the runtime stack expression temporary management routines for SOPA.
Also, I did discuss some SOPA subroutine linkage issues with Peter Nye;
we seem to have cleared up a few points.
Next two weeks:
1. Pass all of my classes.
2. Try to get the expression temporary routines cleaned up and installed
in SOPU (during the latter half of Finals Week).
Thereafter:
I will be out of town between 12/15 and 1/6, then I will be studying for
the Comprehensive Exam, and then I can get down to doing some real SOPA
hacking and document revision (since I am taking a relatively light course
load next quarter).
∂10-Dec-79 1839 CSD.NYE at SU-SCORE Progress report
Date: 10 Dec 1979 1829-PST
From: CSD.NYE at SU-SCORE
Subject: Progress report
To: s1sopa at SU-AI
I have been spending kmost of my time trying to extract from ARR as much
information as possible about UPAS before he leaves.
In the future:
1. More debugging of UPAS/SOPU.
2. Implementiation of proposed option format in UPAS.
3. Implementation of option to specify "new runtimes" (to allow BLH
to debug runtimes)
4. Helping Phil to get linkage stuff in (doing some crucial parts
myself)
5. Bringing up UPAS on S-1.
I am hoping that someone will be found soon to maintain UPAS; but since
debugging of runtimes can't happen without a working UPAS (and SOPU), I will
probably be doing the bug killing for a while.
-------
∂21-Dec-79 2250 ME
To: S1 at SU-AI
The S1 UDP data has been transferred to the real S1 UDP, which is
now available. The temporary S1 UDP will be kept around (hidden) for a
few days to make sure there isn't any trouble with the new pack.
∂27-Dec-79 2046 JBR MOVMQ proposal
To: S1ARCH at SU-AI
PMF and I would like to propose the elimination of the MOVMQ.128 instruction
from the architecture. The reason is one of implementation, namely, that it
is not possible to load all the operands of a MOVMQ.128 into the operand queue
at one time. This allows the cache coherency scheme to have deadlock cases.
All of the other MOVMQ, MOVMS and ALLOC cases will fit in the operand queue.
Two MOVMQ.64 instructions will take almost exactly the same time.
∂30-Dec-79 1640 JMB
To: "@S1ARCH[DIS,S1]" at SU-AI
∂27-Dec-79 2046 JBR MOVMQ proposal
To: S1ARCH at SU-AI
PMF and I would like to propose the elimination of the MOVMQ.128 instruction
from the architecture. The reason is one of implementation, namely, that it
is not possible to load all the operands of a MOVMQ.128 into the operand queue
at one time. This allows the cache coherency scheme to have deadlock cases.
All of the other MOVMQ, MOVMS and ALLOC cases will fit in the operand queue.
Two MOVMQ.64 instructions will take almost exactly the same time.
[I see no problem. -jmb]
∂31-Dec-79 0028 JBR Proposed ACCESS MODES definition
To: s1arch at SU-AI
The following is a proposal (from TM and JBR) for the ACCESS MODES
in the page table and segmentito descriptor words:
WRITE PERMIT <0>
EXECUTE PERMIT <1>
READ PERMIT <2>
I/O PAGE <3>
The other two bits from the old ACCESS MODE field would be returned to the
spare pool. Notice two things:
1. Cache control bits have been deleted. All locations are cached (see
messages of 26-Oct-79).
2. It is now possible to have read-only and write-only I/O pages.
∂31-Dec-79 1242 DLW at MIT-AI (Daniel L. Weinreb) Proposed ACCESS MODES definition
Date: 31 DEC 1979 1539-EST
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: Proposed ACCESS MODES definition
To: s1arch at SU-AI
The new proposal looks good to me. Something else that must be
resolved is how the two sets of bits from the SDW and PTW get combined.
With the new, simpler format now proposed, a simple bit-by-bit boolean
operations would work fine. I need to be able to have SDWs that give
write access to a segmentito while certain PTWs within that segmentito
deny write-access (that is, I would like to have read-only pages within
a segment in hardware, although that is not what it will look like to
programs, as explained somewhere in ADN-7), and so I would not like the
boolean operation used to be "IOR". "AND" or "XOR" would be fine.
∂07-Jan-80 1540 JBR ADJSP proposal
To: s1arch at SU-AI
The currently defined ADJSP instruction adds OP2 to OP1 with address
arithmetic in order to use bounds checking hardware. This will be
relatively slow in the Mark IIA implementation, since it requires
recirculating an operand value to the address arithmetic. A faster
definition would have Address(OP2) be the new value for the stack pointer.
It would move Address(OP2) to OP1 and check it against the stack limit
(NEXT OP1). There would only be one precision of this instruction.
Addressing arithmetic would take the place of the implicit shifts
involved in the old definition. This also makes it analagous to
ALLOC which sets SP from Address(OP2).
∂12-Jan-80 2129 ARK S-1 Meeting
To: S1 at SU-AI
CC: Pickering at SUMEX-AIM
There will be an S-1 Meeting on Thursday, 17 January at 10:30 am and probably
in MJH 301. If you cannot attend, please inform me when you CAN attend. The
time of future meetings will be considered. Budgetary considerations will also
be discussed. Progress reports should be sent to your area distribution list,
e.g., S1SOPA, with a copy to #PROG.LOG[DOC,S1]. Do NOT send your progress
report to @PROG[DIS,S1]. Thank you.
Arthur
∂12-Jan-80 2147 ARK Progress Reports
To: S1 at SU-AI
Sorry, but progress reports should be sent to the area distribution list
plus #PROG.[DOC,S1] (the dot is important), and not to #PROG.LOG[DOC,S1]
nor @PROG[DIS,S1]. Thanks.
Arthur
∂12-Jan-80 2218 ARK Progress Reports
To: S1 at SU-AI
One more attempt at correction:
Sorry, but progress reports should be sent to the area distribution list
plus #PROG.[LOG,S1] (the dot is important), and not to #PROG.LOG[DOC,S1],
#PROG.[LOG,S1], nor @PROG[DIS,S1]. Thanks.
Arthur
∂15-Jan-80 1944 SJC Comments?Objections?
To: "@S1ARCH[DIS,S1]" at SU-AI
Proposed: Indexed constant addressing and %12
Coding %12 in indexed constant mode refers to register %12 rather than to
the PC.
#[FOO](%12.)
∂15-Jan-80 2132 Daniel L. Weinreb <DLW at MIT-AI> Comments?Objections?
Date: 16 January 1980 00:33-EST
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: Comments?Objections?
To: "@S1ARCH[DIS,S1]" at SU-AI
I agree. %12 should mean register %12 when used for indexing and
mean the PC when used as a base register.
∂16-Jan-80 0654 TM
To: "@S1ARCH[DIS,S1]" at SU-AI
∂15-Jan-80 1944 SJC Comments?Objections?
To: "@S1ARCH[DIS,S1]" at SU-AI
Proposed: Indexed constant addressing and %12
Coding %12 in indexed constant mode refers to register %12 rather than to
the PC.
#[FOO](%12.)
[Sounds ok to me. Tom]
∂16-Jan-80 1608 PN Progress, plans, and State of the World As I See It Message
To: s1sopa at SU-AI, "#PROG[LOG,S1]" at SU-AI
I am going to be out of town all day Thursday, and there seems to be no other
time to have the meeting this week, so I will make this as detailed as I can.
SOPU
State of debug: Last quarter, I got SOPU to the state that it translated
itself and PCPASC correctly (as I remember), and a few other large programs,
using PCPASC followed by PTRANS
for the first part of the compilation. This is what I spent just
about all of my time on until the move. I was just about to try them out on
the S-1 to make sure when the system went down. (I haven't had access to the
S-1 since then.) It also seemed to be doing O.K. with Fortran and UPAS Ucode.
I expect future bugs to be mostly where UPAS generates UCode constructs that
PCPASC never did. The following are still unimplemented:
1. Double word reals and integers.
2. multiple set (MUS) instruction, generated by the expression [X..Y], where
X and Y are integer variables
Linkage/register allocation: I got SOPU to put local variables in
registers as assigned by PTRANS and UPAS. This can be used to make simple
programs run faster. I installed display-collapsing once, but plan to
re-install it as a run-time option. The major piece still waiting is PEG's
expression temporary allocation scheme. The new linkage convention will
probably be a part of that. This should be given high priority, since
UPAS will not run on the S-1 without it (it exceeds the old "Program too
complex" limit, because of its use of sets and high level of nesting). I
am hoping that all this, too, will be installed as a run-time option,
chiefly so that we can all work on the same copy of SOPU, but also so
that I can take measurements on the results.
Procedures as parameters (for Fortran only): I worked on this some, but
shelved it because of other priorities.
I will probably do most future SOPU work in conjunction with Russ, to
help him get used to SOPU faster.
UPAS
When ARR left, a number of small, elementary, but thorough
test programs I gave him turned up some bugs, which he fixed. From this
I gather that it is on its way to be user useable, but not there.
Fortunately, Andre Broder will be maintaining it, I hear, in addition
to doing Pascal* work, and BLH is doing some bugfixing already, so
I can spend my time merely turning up bugs and fixing the SOPU end of
them.
Runtimes
I felt pretty satisfied with the runtimes as we agreed on them at the
end of last quarter. I need to put in some time going over the specs,
especially for the kernels, and then install a run-time switch in UPAS
to help BLH's debugging.
Fortran
I haven't been able to do any Fortran maintenance on the S-1 lately.
There is still has one bug outstanding (found by RK). I am hoping to
teach FC enough so that he can take over this rather time-consuming task.
I got ahold of some standard Fortran tests that supposedly put the
compiler through its paces. FC is working on them now, I believe.
Docmementation
I still have one document (on PAS, PTRANS, and VERCH) outstanding.
It shouldn't take very much work, as it is mostly combining existing
documents.
A side note: revising SOPADOPE would be a very time-consuming effort
and could probably be done only by me or PEG or me, who are both critically
needed to do other things. How about if Polle just put out what she has
as an addendum?
PLANS (in summary)
Next week (all time estimations should be multiplied by the usual
underestimation factor):
1. Solidify runtime kernels (1 day)
2. Finish document (1-2 days)
3. Clean up UPAS options (1 day)
Continuing on, in parallel:
4. Continue with UPAS/SOPU debugging
5. re-install display collapsing (with Russ?)
6. teach FC about S-1
7. review runtime specs
∂16-Jan-80 1758 CSD.STEINWEG at SU-SCORE Progress report
Date: 16 Jan 1980 1758-PST
From: CSD.STEINWEG at SU-SCORE
Subject: Progress report
To: s1sopa at SU-AI, csd.steinweg at SU-SCORE, #prog.[log,s1] at SU-AI
current state:
Have finished orientation/reading phase, and can now get
down to some serious business. Over vacation, read the
following documents:
SOPAIPILLA maintenance manual [SOPADOPE-1]
S1 Linkage Protocol [LP-2]
S1 Intermediate Loader Format [LDI-8]
S1 P-Code Runtime Functional Specifications [PRUN-0]
portions of S1 P-Code Intermediate Assembly Languge [PAIL-4]
(the latter was necessary because a knowledge of P-Code,
as opposed to U-Code, was needed to understand SOPADOPE])
next two weeks:
1. get acquainted with SAIL environment, particularly issues
such as how to run S1 programs, where everything is located, etc.
2. get into SOPU, probably by accompanying Peter when he makes
changes to it.
Russ Steinweg
-------
∂19-Jan-80 1548 JBR New hard trap
To: s1arch at SU-AI
The processor should hard trap on any instruction that restores processor
status and instruction state so that instruction state becomes non-zero and
trace pending gets set. That way you cannot inadvertently return to
the middle of a restartable instruction with a trace trap pending.
∂19-Jan-80 2345 MOON at MIT-MC (David A. Moon) Additional Vector Instructions Proposal
Date: 20 JAN 1980 0247-EST
From: MOON at MIT-MC (David A. Moon)
Subject: Additional Vector Instructions Proposal
To: s1arch at SU-AI
It could prove useful to have vector instructions that implement the
"reduction" and "inner product" notions of APL. A few of these exist
now; the ADD/MULT inner-product exists (under the name VDOT), but there
also applications for AND/OR and OR/AND inner products. The LBITCNT
(count the total number of 1 bits in a vector) and LMINMAX (return the
smallest and largest elements of a vector) are reduction-like operations,
but reductions of ADD, MULT, AND, and OR also have applications. These
belong in the architecture since as vector instructions implemented
by clever microcode they can execute roughly four times as fast as
a macrocode loop.
For those unfamiliar with APL, the "+" reduction of a vector V[1..N]
is V[1]+V[2]+ ... +V[N], and the +/* inner-product of vectors
V[1..N] and W[1..N] is the "+" reduction of the vector V*W.
∂20-Jan-80 1400 Mark.Sherman at CMU-10A Datacomputer going away
Date: Sunday, 20 January 1980 1658-EST
From: Mark.Sherman at CMU-10A
Subject: Datacomputer going away
To: S1 @ SU-AI
Message-ID: <20Jan80 165858 MS40@CMU-10A>
As per the following notice, the Datacomputer facility at CCA is going
away. All those with files stored there should retrieve them in the
next couple of weeks and move them to mag tape (assuming you want to
still save them). While some people are making efforts to keep the
Datacomputer on net, I don't think they will succeed. The S1 root is
named, appropriately, "S1".
-Mark Sherman
Date: 20 JAN 1980 1124-EST
From: JZS at CCA (Joanne Z. Sattley)
Subject: Scheduled termination of Datacomputer Service
I have been requested by ARPA to distribute the enclosed message.
***** begin enclosure
To All Datacomputer Users:
The TBM-based Datacomputer has become too expensive to operate.
We are faced with a combination of increasing maintenance costs
and a funding deficit which was created when a major user community's
need for the service ended. The Ampex TBM hardware is obsolete,
and no compatible follow-on product is planned. Therefore, with
much regret, we have decided that Datacomputer service on the ARPANET
must be terminated.
We want to make the transition off the Datacomputer as painless
as possible for existing users. On the other hand, we want
to phase out the service as quickly as possible to avoid
needless expense.
Our plan is to stop accepting any additional files for storage,
effective immediately. The Datacomputer will continue to operate
for retrieval only during the transition period. We would like
users to retrieve their private files by March 15, 1980. DFTP
public files will be saved automatically by the CCA staff.
We apologize for any problems which this decision causes you.
If there is something specific we can do to ease the transition,
we will do our best to help. Send a message to JZS@CCA if you
have questions or need assistance.
Bill Carlson
Program Manager
DARPA/IPTO
***** end enclosure
It has been a genuine pleasure working with all of you.
For the Datacomputer Staff,
-- Joanne
∂20-Jan-80 2259 DLW at MIT-AI (Daniel L. Weinreb) SWITCH versus TDBP in proposed changes
Date: 21 JAN 1980 0200-EST
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: SWITCH versus TDBP in proposed changes
To: S1ARCH at MIT-AI
The SWITCH instruction in SMA3.CHG is intended to load up all the magic
processor registers that need to be switched when a new task is to be
run. However, in the new trap proposal in SMA3.CHG, a different
instruction, namely WRTDBP, is used to load the TDBP from which the
locations of the trap vectors are found, including the soft-trap
vectors for the user rings which should be user-settable in any
reasonable operating system. SWITCH should somehow manage to also
change the locations of the soft-trap vectors. The hard-trap vector,
the interrupt vector, and the TRPEXE vector are unlikely to change when
you switch tasks and so should probably continue to be under the cotrol
of some instruction other than SWITCH.
∂20-Jan-80 2305 DLW at MIT-AI (Daniel L. Weinreb) New instruction: VEXCH
Date: 21 JAN 1980 0206-EST
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: New instruction: VEXCH
To: S1ARCH at MIT-AI
I propose adding a vectorized version of EXCH, to exchange two
contiguous blocks of data. The format is pretty obvious: OP1 and OP2
are the two vectors and SIZEREG holds the length. There is no overwhelmingly
urgent need for this; it just seems useful (I have had occasions to
use it), it seems like it might run a lot faster as an instruction,
and it fits comfortably into the architecture.
∂22-Jan-80 0759 GLS at MIT-AI (Guy L. Steele, Jr.) Proposed changes to %12 in indexed constants, and also ADJSP
Date: 22 JAN 1980 1100-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Proposed changes to %12 in indexed constants, and also ADJSP
To: s1arch at SU-AI
I favor both of these. While ADJSP would come in only
one precision, presumably it would still have the {UP,DN} modifier.
∂22-Jan-80 0806 GLS at MIT-AI (Guy L. Steele, Jr.) Counter-proposal or additional proposal to MOVIF
Date: 22 JAN 1980 1107-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Counter-proposal or additional proposal to MOVIF
To: s1arch at SU-AI
CC: GLS at MIT-AI
I might suggest a TOP SELECT: DEST_if DEST=0 then S2 else S1.
Note that the T=0 case is useful. Alternatively, an XOP:
ONEOF{RTA,RTB}: {RTA,RTB}_if {RTA,RTB}=0 then OP2 else OP1.
The real problem, of course, is that these are all special cases
of a four-operand instruction: DEST_if S1 then S2 else S3. Sigh.
∂22-Jan-80 0825 GLS at MIT-AI (Guy L. Steele, Jr.) Restricted rotate count
Date: 22 JAN 1980 1111-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Restricted rotate count
To: s1arch at SU-AI
CC: GLS at MIT-AI
Presumably the rotation count operand for {Q,H,S,D}
can actually be in the range {-9,-18,-36,-72} ≤ operand ≤ {9,18,36,72}
under the proposal? (That is, the sign of the operand doesn't
matter as long as the magnitude is in range, and a negative operand
effectively flips the {LF,RT} modifier?}
∂22-Jan-80 0825 GLS at MIT-AI (Guy L. Steele, Jr.) Changing CMPSF to XOP format with {RTA,RTB} modifier
Date: 22 JAN 1980 1123-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Changing CMPSF to XOP format with {RTA,RTB} modifier
To: S1ARCH at MIT-AI
CC: GLS at MIT-AI, rpg at SU-AI, rod at SU-AI
It would be POSSIBLE for LISP to generate code with this instruction;
it would just entail rewriting a fair portion of the code generator
for the LISP compiler (the part that compiles predicate tests, etc.,
and the part that does register allocation to know that predicates
may require an RT register). Right now the TOP format is assumed
and used moderately much.
∂22-Jan-80 0932 PMF
To: s1arch at SU-AI
∂22-Jan-80 0825 GLS at MIT-AI (Guy L. Steele, Jr.) Restricted rotate count
Date: 22 JAN 1980 1111-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Restricted rotate count
To: s1arch at SU-AI
CC: GLS at MIT-AI
Presumably the rotation count operand for {Q,H,S,D}
can actually be in the range {-9,-18,-36,-72} ≤ operand ≤ {9,18,36,72}
under the proposal? (That is, the sign of the operand doesn't
matter as long as the magnitude is in range, and a negative operand
effectively flips the {LF,RT} modifier?}
[pmf - No, it turns out to be fairly difficult to implement negative rotates
in the Mark IIa. Considering that they are not really very useful, I would
strongly prefer to not allow them. If someone has some good reason... ]
∂22-Jan-80 1101 GLS at MIT-AI (Guy L. Steele, Jr.) FLT←OVFL←MODE
Date: 22 JAN 1980 1315-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: FLT←OVFL←MODE
To: s1arch at SU-AI
SHould FLT←OVFL←MODE=3 cause NAN to be stored???
∂22-Jan-80 1231 JMB
To: "@S1ARCH[DIS,S1]" at SU-AI
∂22-Jan-80 0806 GLS at MIT-AI (Guy L. Steele, Jr.) Counter-proposal or additional proposal to MOVIF
Date: 22 JAN 1980 1107-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Counter-proposal or additional proposal to MOVIF
To: s1arch at SU-AI
CC: GLS at MIT-AI
I might suggest a TOP SELECT: DEST_if DEST=0 then S2 else S1.
Note that the T=0 case is useful. Alternatively, an XOP:
ONEOF{RTA,RTB}: {RTA,RTB}_if {RTA,RTB}=0 then OP2 else OP1.
The real problem, of course, is that these are all special cases
of a four-operand instruction: DEST_if S1 then S2 else S3. Sigh.
[I kind of like the top format one. -jmb]
∂22-Jan-80 1254 PMF Observation
To: s1arch at SU-AI
This has probably been noted before but...
For the reversed form of TOP's, modes 2 and 3 are redundant, since
they have equivalent forms in the normal operation with reversed OP1
and OP2, i.e.
FSUBV RTA,X,Y
is equivalent to
FSUB RTA,Y,X .
A quick calculation shows that this saves 206 opcodes. We would have
to invent a VOP(?) format which only had modes 0 and 1 of the TOP
instructions. This is similiar to the SKP change that was made some time
ago.
∂22-Jan-80 1335 GLS at MIT-AI (Guy L. Steele, Jr.) VOP
Date: 22 JAN 1980 1632-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: VOP
To: S1ARCH at MIT-AI
You bet it's been proposed before. Do it! Save them
opcodes! (And put in the LISP ones...)
∂30-Jan-80 1526 JMB
To: s1sopa at SU-AI
∂30-Jan-80 0934 PN Packed structures in SOPU
I would suggest the following approach to dealing with packed structures.
Don't do it in Sopa. Instead, implement special load and store byte
Ucode instructions which are introduced in UPAS.
There are two reasons why I think this is the proper approach. First off,
only Pascal which has packed structures are affected. Fortran is not.
Second, there are no major machines for which bit addressing is completely
symmetric with other kinds of memory references. Consequently, special
operators represent the actual kinds of coercion which is necessary to
extract or deposit bytes on real, interesting machines.
An implementation argument is that "bytes" directly appear on the virtual
stack as full-sized data.
There are essentially two kinds of operations needed. (1) Operations on
bytes located in structures (i.e. words) with a fixed bit offset.
These are essentially the kind of operations which can be implemented
with the S-1 immediate byte instructions. LOD, ILOD etc. as we presently
have them can be interpreted as these forms of operations. One must
merely remember that byte access are too complicated to defer and must
be processed when first seen. (2) Operations on bytes with a non-constant
offset. This is for bytes which appear in arrays. There are no such
operations now in Ucode. I would suggest implementing the abstraction
of a bit pointer type, which consists of a regular pointer and non-constant
offset. For the S-1 this would implemented as a byte pointer. On other
machines, you would actually have the two values. Operations:
CBPTR <offset> <length>
Convert address on stack to bit pointer with the specified *constant* offset.
(The length is given for those who want to use byte pointers.)
IXBPTR <length>
Advance bit pointer at stack top - 1 by stack top elements <length> bits
long.
IBLOD <type> <length>
Load byte addressed by the bit pointer on top of the stack.
IBSTR <type> <length>
Store byte into location addressed by the bit pointer on top of the stack.
The introduction of the special bit pointers should eliminate problems
related to common subexpression analysis and strength reduction. You
cannot otherwise deal with two kinds of pointers.
This should also permit a timely implementation for the Mark-IIa
∂30-Jan-80 1633 CSD.BRODER at SU-SCORE New UCODE opcode proposal
Date: 30 Jan 1980 1634-PST
From: CSD.BRODER at SU-SCORE
Subject: New UCODE opcode proposal
To: s1ucode at SU-AI
This is a proposal for the following opcode :
VMOV - Variable move
copies a block from the address on the top of stack to the
address that is second in stack. The length of the block
is the third element in stack. The two addresses and the
length are popped from the stack.
Such an opcode would eliminate the need for loops when dealing
with assignments to parametric type variables in PASCAL*
The code generator could translate VMOV directly on machines
having similar opcodes ( like IBM370 - MVCL) or could generate a
loop on other machines.
Of course it is possible for a smart code generator to recognize
replaceable loops in UCODE but it is easier for everybody to have
a variable length move.
Please send any comments to ABZ@sail.
-------
∂31-Jan-80 0801 CSL.JLH at SU-SCORE packing
Date: 31 Jan 1980 0803-PST
From: CSL.JLH at SU-SCORE
Subject: packing
To: s1sopa at SU-AI, s1pas at SU-AI
∂30-Jan-80 1526 JMB
o: s1sopa at SU-AI
∂30-Jan-80 0934 PN Packed structures in SOPU
I would suggest the following approach to dealing with packed structures.
Don't do it in Sopa. Instead, implement special load and store byte
Ucode instructions which are introduced in UPAS.
There are two reasons why I think this is the proper approach. First off,
only Pascal which has packed structures are affected. Fortran is not.
Second, there are no major machines for which bit addressing is completely
symmetric with other kinds of memory references. Consequently, special
operators represent the actual kinds of coercion which is necessary to
extract or deposit bytes on real, interesting machines.
[The Pascal compiler implements packing to the bit level for record fields. Hence
byte instructions are not sufficient.]
The introduction of the special bit pointers should eliminate problems
related to common subexpression analysis and strength reduction. You
cannot otherwise deal with two kinds of pointers.
[ Thats why we uniformily use bits.]
This should also permit a timely implementation for the Mark-IIa
[ To implement byte packing does not require major changes in Sopu, it can
assume that no bit packing is occurring and divide all offsets by the byte or
word length. The compiler will do only byte packing by changing one switch.]
-------
∂31-Jan-80 1132 HWC
To: s1sopa at SU-AI, s1pas at SU-AI
Byte Hacking - from JMB
I think you are very confused. Its probably my fault for being obscure,
and in that I apologize.
What I am talking about *is* access to generalized packed fields, not
quarter-words. That is, I mean byte in the sense of PDP-10 bytes.
I am proposing that a bit pointer abstraction be added to the Ucode
virtual machine.
∂31-Jan-80 0801 CSL.JLH at SU-SCORE packing
Date: 31 Jan 1980 0803-PST
From: CSL.JLH at SU-SCORE
Subject: packing
To: s1sopa at SU-AI, s1pas at SU-AI
∂30-Jan-80 1526 JMB
o: s1sopa at SU-AI
∂30-Jan-80 0934 PN Packed structures in SOPU
I would suggest the following approach to dealing with packed structures.
Don't do it in Sopa. Instead, implement special load and store byte
Ucode instructions which are introduced in UPAS.
There are two reasons why I think this is the proper approach. First off,
only Pascal which has packed structures are affected. Fortran is not.
Second, there are no major machines for which bit addressing is completely
symmetric with other kinds of memory references. Consequently, special
operators represent the actual kinds of coercion which is necessary to
extract or deposit bytes on real, interesting machines.
[The Pascal compiler implements packing to the bit level for record fields. Hence
byte instructions are not sufficient.]
The introduction of the special bit pointers should eliminate problems
related to common subexpression analysis and strength reduction. You
cannot otherwise deal with two kinds of pointers.
[ Thats why we uniformily use bits.]
[[This is not in fact the case. When you perform an IXA, what you get
back from Sopa is a normal quarter-word addressed pointer. In fact what
you need to get back in the case of a bit-packed array is something which
addresses to the quarter-word level plus offset. In order to do this,
you are going to have to be extreme careful and clever in Sopu and any
optimizations which get written to keep track of the kind of pointer which
you have on the stack.
The problem is much more easily solved in the front end -- judging from
the experience of Pascal-10 -- and it is solved once, not n times in n
code generators. Introducing bit pointers in the manner in which I described
does not restrict implementations unnecessarily. There is no real, interesting
system for which bit addressing is possible.]]
This should also permit a timely implementation for the Mark-IIa
[ To implement byte packing does not require major changes in Sopu, it can
assume that no bit packing is occurring and divide all offsets by the byte or
word length. The compiler will do only byte packing by changing one switch.]
[[This is not the impression that I got from PNs last message.]]
-------
∂31-Jan-80 1945 PMF
To: s1arch at SU-AI
The following is a description of a general mechanism for interprocessor
synchronization. The need for it arose during the analysis of SIMPLE, but
I believe that it will be a generally useful mechanism. In looking at
SIMPLE, EJG and I discovered that the normal interprocessor communication
mechanism, main memory with cache coherence, is sometimes too "bulky". By
this I mean that sometimes it is very important to pass small packets of
data with very little overhead at medium bandwidths. The cache coherence
scheme deals with 16-word chunks, which are sometimes far too large.
There is also the problem of passing synchonization information in a
reasonably low overhead way.
The main features of the following protocol are that it allows the
operating system complete control of interprocessor communication,
including the capability to allocate and deallocate links (essentially
allows them to be demand paged) and more importantly allows for a high
speed implementation, with very little overhead to the program itself (the
overhead is handled by the MSEQ and the Switch).
Comments should be made soon, I want to include this in SMA-4.
SNDMSG SOP
OP1 is a LINK (format described below) and OP2 is a doubleword of data.
SNDMSG sends OP2 on the LINK and skips if the message was successfully sent,
otherwise the direct return is taken.
RCVMSG SOP
OP1 is a doubleword and OP2 is a LINK. If there are any messages
pending on LINK, RCVMSG will return the next message (a double-word) in OP1
and skip return, otherwise the direct return is taken.
A LINK is a I/O location with a special format.
The LINK must have I/O page set in the access bits and one (and only one)
or read or write access. Thus a link is unidirectional.
The 34-bit physical address is interpreted as follows:
Bits Use
PA<0:6> 1 (trap if not)
PA<7:22> pointer to LINK_DESCRIPTOR (in link IOMEM)
PA<23:33> ignored
** This above is all that the user need know. The following is what the
operating system has to know of the implementation.
There is a special I/O memory in each processor for use by the
synchonization instructions (henceforth call the SYNCH I/O memory). This
I/O memory is shared between the ABOX and MSEQ. The ABOX is also able to
somehow tell the MSEQ that there is some work that needs to be done.
Since this is a I/O memory, the operating system is free to use normal
I/O memory instruct
Next two weeks:
1. Implement an EXPRESSION TEMPORARY MANAGEMENT class
After that:
1. Interface it with SOPU
2. bit-packing
Russ
-------
∂12-Feb-80 2305 JBR
To: s1arch at SU-AI
Why is there no UDIVV, UDIVLV?
A recently accepted architecture change was to consider (OP,NEXT_OP) for
QW and HW pairs to be of the next higher precision for all instructions
except DSHF and DSHFV. I would like to propose that this be extended to
singleword (OP,NEXT_OP) pairs as well. This will have little effect on
programmability, as doublewords need not be aligned but will speed up the
execution of those instructions for which the ABOX can make use of both
words being delivered in the same cycle.
The effect this will have on the architecture is in the way constants are
treated for this case. Previously, it would have been illegal to use a
constant where (OP,NEXT_OP) was expected in the single and double word
cases. With this change, a double word constant could be used where a
single word (OP,NEXT_OP) is expected. This change cannot be extended to
doublewords due to the lack of a quadword precision.
This brings up the topic of exactly how constants should be treated for
(OP,NEXT_OP) cases and for "multiple" precision instructions like MOVMS
and vector instructions. These instructions have an inherent precision;
e.g., single word for MOVMS. I propose that when a constant is supplied
to such an instruction that the constant be replicated at the inherent
level of precision.
As an example, MOVMS.3 MEM,#6 would move the single word constant 6
into locations MEM, MEM+4 and MEM+8. Thus, MOVMS.32 %0,#0 would
clear all the registers. The hardware of the Mark IIA is set up to
do this quite efficiently. Since this applies to vector instructions
as well, it would be possible to pass a "vector constant" to any vector
instruction merely by using a constant as the operand where a vector is
expected.
In some of the SMAs and SMA.CHGs the NEXT function has been used to
describe instructions like DIVL or BNDTRP.B and has also been used (inside
of a loop) to indicate the operation of instructions like ALLOC and MOVMS.
For the DIVL class, we have already agreed that the QW, HW (and with the
above proposal, SW) versions do not perform a NEXT operation; they merely
increase the precision to the next level. So the remaining representative
from that class is BNDTRP.B.D which expects to fetch (OP1,NEXT_OP1).
I propose (as a logical extension of the above proposal) that when a
constant is supplied for a double word (OP,NEXT_OP) that the double word
constant be replicated.
The final part of this proposal nails down how the three types of extended
constants behave when an instruction is not expecting a double word constant.
The answer is simply that they all behave the same. In other words, the
sign extension, zero extension, and left adjusting of the extended constant
only applies where a double word constant is expected (in the context of the
above proposal). When a quarter, half, or single word constant is expected,
only the low order part of the single word constant is used.
∂13-Feb-80 1155 PEG Progress Report
To: s1sopa at SU-AI, s1progress-log at SU-AI
Last few weeks:
1. Took both parts of the Comprehensive Exam.
2. Got mostly caught up in my classes after (1).
3. Worked with PN and FC on debugging U-Code FORTRAN.
4. Got RUS started on finishing and installing the set of expression-
temporary management routines that I began, in consultation with
PN and PTZ. There will be two stages to this implementation, the
first of which RUS will do and which is needed for the new linkage
convention which I plan to install later this quarter.
Future:
1. Finish the S1INT-1 document (soon).
2. Work on SOPADOPE-2 document (with PN).
3. Install new linkage convention in SOPU.
Phil Gerring
∂13-Feb-80 1818 PN prgrss 'n plns
To: s1sopa at SU-AI, "#PROG[LOG,S1]" at SU-AI
New heights: UPAS and SOPU now, in combination, correctly translate
PCPASC, PTRANS, and all the small programs I can find.
This is a result of an intensive two weeks of bug-killing
that turned up 16 UPAS bugs, 5 SOPU bugs, and 1 PCPASC bug. These bugs
are temporarily recorded in BUG.LOG[TST,S1].
Coming up:
1. Revise and expand User's Guide.
2. Give PEG any help he needs with SOPADOPE.
3. Help FC with S-1.
4. Various UPAS clean-ups.
5. More debugging.
∂13-Feb-80 2308 PTZ progress report
To: s1sopa at SU-AI, "#PROG.MSG[LOG,S1]" at SU-AI
Past six weeks:
Have been working on an update to SOPADOPE describing the internals of
the peephole optimizer, rationale for the choice of optimizations
implemented, results of the optimizations, etc.
Simultaneously have been implementing a new algorithm for
making skips and jumps their minimal size and testing its operation
with respect to speed, space, and the quality of the output code.
Future:
I hope to be done with the above at any moment, and then I will work
on my debugger research and also getting the peephole optimizer
ready for RUS and PEG's new temporary mamagement and linkage convention.
The documentation phase has also pointed out a number of new optimizations
that would be easy to implement.
Polle
∂13-Feb-80 2331 BLH Progress Report...
To: s1sopa at SU-AI, s1progress-log at SU-AI
CC: BLH at SU-AI
Although I am 0% time on S-1 this quarter, the following progress was made:
Last few weeks...
1. Chasing more bugs in SOPU and UPAS by debugging the runtimes.
2. Another revision of PRUN-1 meets the scrutiny of the masses...next
version will be off to the printers.
Next few weeks...
1. Last revision of PRUN-1 and send it to the printers (and to
GIo)
2. More debugging of runtimes as time permits.
--- Bruce L. Hitson
∂15-Feb-80 1344 PEG Release of new UCode SOPA
To: s1sopa at SU-AI
A new version of UCode SOPA has been released as SUPG04. It includes one
major change and many small bugfixes that had been incorporated into SUPG03
since its release.
The new feature is the support of long (double precision) real arithmetic
(UCode type Q) and related operations. All changes are marked "peg 14feb80".
Important notes on this change:
1. Neither FSIM nor the S-1 Mark I hardware support double-precision
real operations (yet?).
2. With this implementation, long real CONSTANTS either (1) will not
be able to be read in by the PDP-10 PASCAL runtimes because they are
too big, or (2) if they make it past the runtimes, they will be
truncated to single precision. If the previous item on this list is
ever fixed, I will consider extending the changes to deal more
completely with double-precision constants (which would be 2-3 days
of hacking).
3. The changes are not yet completely tested because of (1), above;
however, the code LOOKS correct (sigh...).
∂15-Feb-80 1727 Purger
To: S1 at SU-AI
You have exceeded your disk quota.
The files listed below are being purged to reduce your disk
usage to your quota of 9000
Before purging, your files occupied 10675
T11.UCO[FOR, S1]
UINT.DO[FOR, S1]
T11.PUT[FOR, S1]
SOPB1A.UCO[FOR, S1]
T12.UCO[FOR, S1]
T13.UCO[FOR, S1]
T2.UCO[FOR, S1]
Q2.UCO[FOR, S1]
PUSE.DO[FOR, S1]
PTRANS.DMP[FOR, S1]
Q1.UCO[FOR, S1]
OUTPUT[FOR, S1]
PFOR.DO[FOR, S1]
SIMPLE.FOR[FOR, S1]
SIMP.DAT[FOR, S1]
T4.UCO[FOR, S1]
Q2FIX.PAS[FOR, S1]
T1.UCO[FOR, S1]
Q2.PAS[FOR, S1]
Q1.PAS[FOR, S1]
SOPB1A.FOR[FOR, S1]
SIMP2B.FOR[FOR, S1]
TEMP1.OUT[FOR, S1]
TEMP.PCO[FOR, S1]
SIMP2B.F4[FOR, S1]
SIMP2B.REL[FOR, S1]
FOR01.DAT[FOR, S1]
PAS1.DO[FOR, S1]
RQR.FF2[FOR, S1]
OUTM[FOR, S1]
FF2TLR.RQR[FOR, S1]
SORT.ASM[FOR, S1]
TITLE.FF2[FOR, S1]
BODY.FF2[FOR, S1]
FF2HDR.RQR[FOR, S1]
FF2.PUB[FOR, S1]
SIMP.FOR[FOR, S1]
SORT.GIO[FOR, S1]
TRIAL.PCO[FOR, S1]
PAS45.TMP[FOR, S1]
TRI.FOR[FOR, S1]
PPSAV.TMP[FOR, S1]
PAS20.TMP[FOR, S1]
FUSE.DO[FOR, S1]
R2.PAS[FOR, S1]
R1.PAS[FOR, S1]
TRIAL.OUT[FOR, S1]
PFHELP.PUB[FOR, S1]
PFSE.DO[FOR, S1]
SOPA.DO[FOR, S1]
FIL0[FOR, S1]
FSIM.DO[FOR, S1]
NBS05.FOR[FOR, S1]
PCFOR1.PAS[FOR, S1]
PAS43.TMP[FOR, S1]
NBS03.FOR[FOR, S1]
PAS27.TMP[FOR, S1]
NBS04.FOR[FOR, S1]
PAS19.TMP[FOR, S1]
NBS09.FOR[FOR, S1]
DFORR.DO[FOR, S1]
NBS10.FOR[FOR, S1]
NBS08.FOR[FOR, S1]
NBS13.FOR[FOR, S1]
PAS41.TMP[FOR, S1]
NBS11.FOR[FOR, S1]
NBS07.FOR[FOR, S1]
NBS06.FOR[FOR, S1]
NBS12.FOR[FOR, S1]
NBS04.D[FOR, S1]
NBS11.D[FOR, S1]
NBS09.D[FOR, S1]
NBS03.D[FOR, S1]
FF2.XGP[FOR, S1]
NBS02.D[FOR, S1]
NBS12.D[FOR, S1]
NBS05.D[FOR, S1]
TRIAL.F2[FOR, S1]
NBS06.D[FOR, S1]
NBS07.D[FOR, S1]
NBS13.D[FOR, S1]
NBS14.D[FOR, S1]
T.LST[FOR, S1]
NBS10.D[FOR, S1]
NBS13.F[FOR, S1]
NBS12.F[FOR, S1]
NBS08.D[FOR, S1]
NBS02.FOR[FOR, S1]
NBS01.PS1[FOR, S1]
NBS01.FOR[FOR, S1]
USFOR2.PAS[FOR, S1]
TEMP.PAS[FOR, S1]
FOR.CMD[FOR, S1]
S1.TXT[FOR, S1]
T9.PS1[FOR, S1]
T9.ERR[FOR, S1]
T9.UCO[FOR, S1]
NBS01.LDI[FOR, S1]
T9.LDI[FOR, S1]
PAS58.TMP[FOR, S1]
NBS01.UCO[FOR, S1]
NBS01.D[FOR, S1]
TRL.FOR[FOR, S1]
TRL.PS1[FOR, S1]
FIL4[FOR, S1]
NBS.NOT[FOR, S1]
TEMP.FOR[FOR, S1]
TRL.LDI[FOR, S1]
TRIAL.PS1[FOR, S1]
TRIAL.UCO[FOR, S1]
NBS14.F[FOR, S1]
TEMP.PS1[FOR, S1]
FIL1[FOR, S1]
TEMP.LDI[FOR, S1]
TEMP.UCO[FOR, S1]
T9.LST[FOR, S1]
SOPU.DO[FOR, S1]
FIL5[FOR, S1]
PAS2.DO[FOR, S1]
PAS26.TMP[FOR, S1]
NBS14.LST[FOR, S1]
NBS14.ERR[FOR, S1]
UCFOR2.PAS[FOR, S1]
TRL.UCO[FOR, S1]
CEXP[FOR, S1]
TRIAL.evel, but not, as has been proposed, to drastically reduce the
resolution, efficiency, and functionality of the interrupt architecture.
Curt
∂13-Mar-80 1608 PMF
To: s1arch at SU-AI
∂13-Mar-80 0847 LCW Interrupt Architecture
To: "@S1ARCH[DIS,S1]" at SU-AI
The old interrupt architecture could definitely use some additional
description:
In the old architecture, a "device" was a single peripheral or group of
peripherals connected to an IOP. If the device contained only a single
peripheral, then the identity of the interrupting peripheral was implicit
in the interrupt vector location. If the device contained more than one
peripheral (e.g., an array of keyboard buffers) then the indentity of the
interrupting peripheral would be discovered by looking at the interrupt
parameter. Allocation of peripherals to devices was done at configuration
time.
It was intended that a peripheral would directly interrupt only the IOP,
and that the IOP would interpret and forward the interrupt to the S-1 by
writing appropriate information into the I/O memory and asking the ABOX
microcode to interpret it and possibly percolate an interrupt up to the
macro level. All interrupt-pending bits and interrupt-enable bits were to
be kept in ordinary RAM in the ABOX for use by the microcode algorithm
which determined whether an IOP interrupt would make it to the macro
level. After sending one interrupt for a particular device, the IOP would
not send subsequent interrupts for that device until the first interrupt
had been serviced.
The old architecture allowed the S-1 to distinguish very efficiently (by
interrupt vector location) between a large fixed number (32) of classes of
interrupting peripherals sharing an I/O memory; the new architecture
requires a protocol to determine which peripheral is interrupting. Not
only is the new architecture less efficient, but since the necessary
protocol has not been defined, some of the definitional problem that was
mentioned in the new proposal has been swept under the rug.
[The new protocol is NOT less efficient. The old protocol simply left
everything to the microcode, both making it MUCH more complex and taking
flexability from the programmer. How does the IOP specify which device is
interrupting in the old protocol? There is no need to specify the device
level protocol in the new scheme, in fact it is better to not specify it,
allowing more flexibility to the user. The obvious way for IOP (in the new
protocol) to specify which device is to have a fixed area of the IOMEM to
use specifing the device and parameters. However some disks might want to
use the entire IOMEM, so that there is no space left for a protocol area.
(These disks exist today.) For these disks, the interrupt for this IOMEM
would mean that the entire IOMEM has been processed! This would not be
possible in the old scheme.]
The old architecture allowed the delivery of an interrupt parameter with
the interrupt. The interrupt parameter was important to allow efficient
operation in spite of long latencies for communication between the IOP and
the S-1; many peripherals could deliver all relevant information about the
interrupt (e.g., the specific peripheral within the device, and a
character or completion code) with the interrupt itself, thus eliminating
the overhead of interrogating the IOP for that information.
[How is there a difference between the microcode reading a fixed word in the
IOMEM in the old scheme and the user reading the same word in the new scheme?
In fact the new scheme allows for arbitrarily many parameter words!
Just in case it hasn't been said enough, THERE IS NO PERFORMANCE DIFFERENCE!]
The old architecture allowed devices sharing an I/O memory to have their
interrupts individually disabled or enabled. The new architecture
simulataneously enables or disables all interrupts for all peripherals
which share an I/O memory.
[Yes, but the IOP can disable a device by order of the S-1. I find this
acceptable, since every plan I have heard so far involves ONE class of device
per IOMEM for most IOMEM's. This allows the capablity of shutting down an
wild IOP and telling the IOP to shut down its own devices if the need arises.]
The old architecture allowed the programmer to directly test whether any
interrupt was pending *without* enabling the interrupt. In the operating
systems that I have written, I have found this capabiliiy to be extremely
important in the interrupt handlers; it was deleted without comment in the
new architecture.
[ This is a good point. I will add the capablity of testing (and
modifying) any particular pending interrupt and testing whether any
interrupts would happen if the processor priority were different.]
In summary, the new proposal represents a step backward. I could be
convinced to add more priority levels, and even more devices per priority
level, but not, as has been proposed, to drastically reduce the
resolution, efficiency, and functionality of the interrupt architecture.
[In summary, the new proposal has no limits on the number of devices, is more
flexible and is at least as fast if not faster.]
Curt
[Mike]
∂13-Mar-80 1618 PMF
To: s1arch at SU-AI
∂12-Mar-80 1056 JMB
To: s1arch at SU-AI
∂12-Mar-80 0200 PMF
To: s1arch at SU-AI
The current I/O interrupt architecture is very underspecified. For
instance, it refers to "devices", but nowhere is a device defined and all
other references to I/O talk about I/O memories. Also it has a limitation
of 32 devices per level and 256 devices total, which is somewhat
arbitrary. After some thought and discussion with DLW, I would like to
propose a much simpler (and hopefully more complete) description of I/O
interrupts.
---------
(1) From what I understand of Navy and other realtime applications, I think
you want more than 8 priority levels. 32 would seem to be about the minimum
that we could get along with. After all, one could have used the old
scheme as if there were 256.
[32 is fine with me.]
(2) How do the I/O memory numbers get assigned?
[The front-end processor loads a register which tells the each S-1 what the
numbers of it's internal IOMEM's are. The external IOMEM's (if any) know
what their IOMEM numbers are.]
(3) The format of interrupt information that gets pushed on the stack wants to
be integrated into the trap proposal. Clearly, what you specified is
incomplete, as we need other state information as well.
[Yes, I will fix this in a new note.]
(4) Could you explain why interrupt parameters were deleted from the proposal?
[They were essentially a S-1 microcode-IOP level protocol using the IOMEM as a
buffer. This seems to be unnecessarily complicated and restrictive. It is much
easier for the user to read the parameters directly from the IOMEM.]
∂14-Mar-80 1058 LCW Interrupt Architecture
To: "@S1ARCH[DIS,S1]" at SU-AI
PMF and WRB and I discussed the new proposal briefly yesterday. I agree
that the specific-device-within-an-IOP identity can be passed in the I/O
memory in a format which is defined by software convention, as can any
interrupt parameters. However, we agreed that the proposal as it
currently stands has some synchronization protocol problems if it is going
to allow individual devices to have their interrupt-enables and
interrupt-pendings set and tested. So the two points I raised earlier
still stand:
The old architecture allowed devices sharing an I/O memory to have their
interrupts individually disabled or enabled. The new architecture
simulataneously enables or disables all interrupts for all peripherals
which share an I/O memory.
The old architecture allowed the programmer to directly test whether any
interrupt was pending *without* enabling the interrupt. In the operating
systems that I have written, I have found this capability to be extremely
important in the interrupt handlers; it was deleted without comment in the
new architecture.
I am not challenging anyone to divert effort to solving these problems,
but if we are going to change the architecture, then the new proposal
should show how to include all the important functionality that we had
before.
Curt
∂14-Mar-80 1619 PN Progress Report
To: s1progress-log at SU-AI, s1sopa at SU-AI
State of the world:
UPAS and SOPU now compile correctly all the programs I have around,
including themselves (using old runtimes).
The new primitive runtimes are mostly done (by JBR).
The new Pascal-coded runtimes are about half done.
HBS1 goes through UCFOR2 and SOPU on the S-1 o.k., but I haven't tried
running it yet.
In the past:
Killed more UPAS and SOPU bugs, most of them (by now) very subtle (i.e.,
took a long time to find). These are recorded in BUG.LOG[PAS,S1].
Rewrote and re-installed display collapsing in SOPU, including
optimization.
Put new,improved tracing mechanisms in SOPU.
Fixed a few things in UPAS to minimize changes between DEC-10 and UPAS
versions of programs.
Put in user-settable register allocation in UPAS. This is for experimental
use only; it will be available but not standard in the exported version.
In the future:
It will take me about another 3-4 days to finish the runtimes. Then I
will have before me a number of things having to do with releasing the new system.
They include:
1. Runtime document
2. S-1 User documentation (USERGD)
3. Small UPAS document
4. Making UPAS more readable
Also:
5. Comparision timing between old and new systems, and among various
register allocation strategies. Since I was by far the prime user
of the SAIL system in February, I am going to try to confine most
of this kind of activity to the S-1. This is made possible by PMF's
of FINE.
6. HBS1
7. Sopadope
8. About a thousand other small details.
∂17-Mar-80 0859 LCW Mistake
To: "@S1ARCH[DIS,S1]" at SU-AI
In case you got a spurious message from me... I meant to send it to Cindy.
Sorry. Curt
∂17-Mar-80 1615 WRB Change in IOBUS Definition
To: "@S1ARCH[DIS,S1]" at SU-AI
See IOBUS[mk2,s1] for the latest in the IOBUS definition.
Comments are welcome.
Bill
∂18-Mar-80 1521 WRB
To: "@S1ARCH[DIS,S1]" at SU-AI
Here is a new, somewhat more complete description of I/O.
I/O interrupts are associated with I/O memories. Devices within I/O
processors are defined by software convention, the S-1 architecture itself
only understands I/O memories and their associated interrupts.
I/O memories are arrays of 36-bit words shared with an IOP. Since many
IOP's are 8 (or 16 or 32) bit machines, the S-1 architecture defines the
mapping between S-1's and 8-bit byte IOP's. Each 8-bit byte of such an
IOP is mapped right-adjusted into an S-1 byte. The high-order bit of the
9-bit I/O memory bytes is set to zero when written by the IOP. The format
of an (34 bit) physical I/O memory address is:
IOBUF_NUM<0:15> : ADDR_IN_IOBUF<0:17> .
The ADDR_IN_IOBUF specifies a quarter-word address within an I/O memory,
however most I/O instructions insist that the I/O addresses be
*single-word* aligned. Each IOBUF in the multiprocessor has a unique
IOBUF_NUM. Since each I/O memory in the multiprocessor has a unique
number, this number may conveniently be used to index into an array of
interrupt vectors, one vector per I/O memory. Note that there is only one
copy of this interrupt vector array for the entire multiprocessor. The
format of an interrupt vector is:
new USER_STATUS
new PROC_STATUS
handler address
reserved for program, not used by interrupt microcode
An I/O memory may interrupt at any one of 31 levels (1-31), determined by
the associated IOP (I/O processor). (This involves increasing the number
of bits in the PROC_STATUS_PRIO to five bits.) The priority levels are in
*increasing* priority, i.e. the interrupt will remain pending (waiting
for processor service) until the interrupt priority is strictly greater
than the processor priority. Note that this is reversed from its previous
definition. When multiple interrupts have priority greater than the
processor priority, the one with the greatest priority is chosen, if
multiple interrupts have the greatest priority, a fixed hardware algorithm
will choose one of the interrupts to service. Note that processor priority
level 31 locks out all interrupts, and with processor priority = 0, no
interrupt levels are locked out.
The processor priority level in the new PROC_STATUS is ignored during the
interrupt, the actual processor priority is set by the IOP causing the
interrupt, i.e. equal to the priority the IOP interrupted at.
An interrupt causes four words of data to be pushed onto the stack (plus
the normal instruction state):
<instruction state, defined elsewhere>
I/O memory number
old USER_STATUS
old PROC_STATUS
PC_NEXT_INSTR.
Each I/O memory has a associated enable bit which allows an S-1 to disable
interrupts from this I/O memory. While an I/O memory is disabled from
interrupting, one interrupt may occur and will remain pending until the
enable bit is set again.
The definition of interrupt I/O instructions are given below. All operands
are treated as SW's. Any reference to an I/O memory not connected to the
processor executing these instructions causes a hard trap.
WIEN (XOP) (Write Interrupt ENable)
ADDR_OP1 is an address in an I/O memory. The interrupt enable bit of
this I/O memory is set to the low order bit of OP2.
RIEN (XOP) (Read Interrupt ENable)
ADDR_OP2 is an address in an I/O memory. The current value of the interrupt
enable bit is returned in OP1; 0 if not enabled, -1 if enabled.
RIPND (XOP) (Read Interrupt PeNDing)
ADDR_OP2 is an address in an I/O memory. The current value of the level of
the pending interrupt (for this I/O memory) is returned in OP1 (0 meaning that
there is no interrupt pending).
WIPND (XOP) (Write Interrupts PeNDing)
ADDR_OP1 is an address in an I/O memory. The current interrupt pending level
(for this I/O memory) is set to OP2 (where 0 clears interrupt pending).
Also there needs to be a new I/O instruction. The other I/O instructions
are mentioned elsewhere, but are repeated here for completeness.
IORMW (TOP) (I/O Read Modify Write)
Works the same as RMW, except that S2 is an IO address, i.e.
indivisibly do: DEST←S2; S2←S1. All operands are single-words.
IOREAD.QHSD (XOP) (I/O READ)
OP1 is set to the contents of I/O locations OP2.
IOWRITE.QHSD (XOP) (I/O WRITE)
I/O memory location OP1 is set to OP2.
VIOR.{B,Q,H,S} (XOP) (Vector I/O Read)
VIOW.{B,Q,H,S} (XOP) (Vector I/O Write)
Described in SMA-4, except that all addresses must be single-word aligned
(even for B, Q and H modes) for both the I/O and memory addresses.
Also the length of the operation is always in single-words. Thus if sizereg
is 4 for a VIOW.B instruction, 4 SW's are translated into 4 1/2 I/O words.
INTIOP (XOP) (Interrupt I/O Processor)
ADDR_OP1 is an address in an I/O memory. The IOP attached to the addressed I/O
memory is interrupted. OP2 is passed to the interrupted IOP. The use of OP2 is
up to the IOP interface.
This eliminates the instructions:
WIPAR, RIPAR, CIPND, SIPND, SIEN, CIEN.
and modifies the meaning of RIPND, WIEN, WIPND, RIEN, INTIOP, VIOW and VIOR.
Mike, Bill
∂24-Mar-80 2319 OTA instruction state
To: "@S1ARCH[DIS,S1]" at SU-AI
Mike has suggested that in conjunction with the matrix multiply instruction
he would like to extend the instruction state from 4 words to 64 words. Any
objections?
∂27-Mar-80 0053 GLS at MIT-AI (Guy L. Steele, Jr.) Yet another FOP
Date: 27 MAR 1980 0318-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Yet another FOP
To: s1arch at SU-AI
CC: GLS at MIT-AI, rwg at SU-AI, rpg at SU-AI
Here's another completely random four-operand instruction
for the S-1 not to implement. Recall, for example, that
a relatively good one is BITMERGE: DEST ← (S1 ∧ ¬ S3) ∨ (S2 ∧ S3).
Here we have a cruftier one: ADDFIELDS. S1 and S2 are added
together and placed in DEST, but S3 divides the word up
into fields. Each 1-bit in S3 marks the right-hand bit of a field.
Carries are not to propagate from one field to the next; hence
if S3 is the binary quarter-word 000101101 then four independent
additions occur: one is mod-16, one is mod-4, one mod-2, and one mod-4.
One can model this as saying that a 1-bit in S3 suppresses the carry
into that bit during the addition. If there were a complete set of
such "field-specified" operations, like SUB, MAX, and MIN, one
could do all kinds of wondrous things. Anyway, here are two
encodings of this operator as S-1 instructions (maybe good examples
for the manual?):
[a] Small but slow (iterative):
MOV R0,S1
MOV R1,S2
LOOP: AND RTA,R0,R1
SHF.LF RTA,#1 ;RTA has the set of carries
XOR R0,R1 ;R0 gets sum done without carries
ANDTC R1,RTA,S3 ;R1 gets carries, masked by S3
JMP.NEQ R1,LOOP ;iterate until carries settle down
[b] Big but fixed-time (this is tricky -- remember a field may be 1 bit!):
ANDTC RTA,S1,S3 ;mask off low bits of S1 and S2
ANDTC RTB,S2,S3 ; and add them together (the missing
ADD RTA,RTB ; low bits of each field absorb carries)
AND RTB,S1,S2 ;calculate carries from low bits explicitly
SHF.LF RTB,#1
ANDTC RTB,S3
ADD RTA,RTB ;add in those carries; at most one carry to
ANDTC RTA,S3 ; next field has happened, so flush them
XOR RTB,S1,S2 ;calculate the low bits for each field
AND RTB,S3 ; by XOR and then masking, and save in R1
OR DEST,RTB,RTA ;merge low-bits and all-but-low-bits
Let me know if I blew it.
-- Quux
∂27-Mar-80 0153 OTA new trap proposal
To: "@S1ARCH[DIS,S1]" at SU-AI
A new proposal for traps that includes most of the features of
the old proposal and additions, especially to make recursive traps work.
Please send commentary, suggestions, typos etc to me and I will
edit them in. The proposal is in trap.pro[1,ota] on SAIL.
The Gate proposal which is briefly mentioned is in gate.pro[1,dlw].
∂27-Mar-80 0957 MOON at MIT-MC (David A. Moon) new trap proposal comments
Date: 27 MAR 1980 1240-EST
From: MOON at MIT-MC (David A. Moon)
Subject: new trap proposal comments
To: OTA at SU-AI
CC: s1arch at SU-AI
Why is the TDBP a physical rather than virtual address?
There is no reason, especially if what it points to is an
array of virtual rather than physical addresses.
Note that the TDB entries for gates don't point to arrays of
descriptors, but only to single descriptor blocks which then
point to arrays of entries.
Hasn't interrupt-parameter been flushed?
There is a problem with soft traps in complex instructions, e.g.
if you get a floating-point overflow in a vector inner product
you can't tell easily whether the overflow was the result of an
add or a multiply. The architecture also doesn't allow for
soft traps associated with intermediate results that are not going
to be stored any place. I don't have any proposal for how to fix this.
Hard trap during a hard trap should simply stop the machine; this
kind of recovery is probably better the province of the front-end
processor, which could do various kinds of recovery and continue
the system.
Should the TDBP be part of the data switched by the SWITCH instruction?
Some of the TDB pointers could conceivably want to be different in different
tasks in the same address space, therefore the TDBP might have to
be different in each task.
RDTDBP may be superfluous. All it would be good for is checking that
the processor really remembers the value written into it.
RETFS.A is superfluous, since it can be done by moving pc←next←instr
into pc, zeroing the first word of instruction-state, and doing RETFS.R,
unless the fault was during instruction fetch, in which case it is
difficult to see how to define a reasonable thing for RETFS.A to do anyway.
Same comments apply to RETUS. Also, is there any reason for RETFS and
RETUS to be different? Maybe RETFS should simply not change PROC←STATUS
if the program is not priveleged, and PROC←STATUS should always be stored
on all traps, in case it is a soft trap in a priveleged ring?
Is 64 words enough instruction state? Wouldn't the state of a matrix multiply
need 64 words for the data plus a few to show where processing had reached?
Or is it 32 words for the data, plus a few?
It might be infinitesimally nicer to put pc←next←instr before instruction←state
rather than after.
Gate-undefined and gate-violation are obsolete.
The comment about hard trap #0 and nested traps is obsolete.
My comment that some of the hard traps should really be soft traps stands.
∂27-Mar-80 2202 JMB
To: s1arch at SU-AI
∂27-Mar-80 0957 MOON at MIT-MC (David A. Moon) new trap proposal comments
Date: 27 MAR 1980 1240-EST
From: MOON at MIT-MC (David A. Moon)
Subject: new trap proposal comments
To: OTA at SU-AI
CC: s1arch at SU-AI
Should the TDBP be part of the data switched by the SWITCH instruction?
Some of the TDB pointers could conceivably want to be different in different
tasks in the same address space, therefore the TDBP might have to
be different in each task.
[It does not much matter one way or another. The switch instruction
changes only as much as is necessary to accomplish a meaningful
context switch - i.e. change the PC and address spaces at the
same time. There is no fundamental reason why the TDBP must be
changed in the same atomic operation. It and the register set
can be changed in instructions preceeding the switch.]
RETFS.A is superfluous, since it can be done by moving pc←next←instr
into pc, zeroing the first word of instruction-state, and doing RETFS.R,
unless the fault was during instruction fetch, in which case it is
difficult to see how to define a reasonable thing for RETFS.A to do anyway.
Same comments apply to RETUS. Also, is there any reason for RETFS and
RETUS to be different? Maybe RETFS should simply not change PROC←STATUS
if the program is not priveleged, and PROC←STATUS should always be stored
on all traps, in case it is a soft trap in a priveleged ring?
[The .R and .A modifiers come from the following line of reasoning.
Consider a scalar instruction which causes a zero-divide in a
situation where the User Status calls for a soft-trap. The
normal fixup is for the trap handler to set the destination and
then continue execution at the next instruction. If a hard-trap
occurs in pushing the soft-trap information, then the hard-trap
is taken instead, and the **same** instruction state is pushed.
After recovery from the hard-trap, then execution is resumed from
the beginning and the soft-trap occurs again.
So this identifies the two typical cases of (1) advance after a
trap, and (2) restart after a trap. And, as you say, the two cases
can be handled by playing with the PC -- but only in the case of
scalar instructions.
If the zerodivide occured on one pair of operands in a vector
instructions, then it is the contents of the instruction state
which identifies the "current" element and hence where to
continue. (Current for the restart case, current + 1 for the
advance case -- we want the same state to that we can punt out
of a soft-trap in the case of a nested hard-trap.) As the
contents of the instruction state should not be made user
visible, it is necessary to make the restart instructions do the
"right thing".
But what is the right thing? The normal cases are: (1) Restart
the instruction for a hard-trap, (2) advance to the next instruction/
operand for a soft-trap, including TRPSLF, and (3) advance to
the next instruction for a TRPEXE. Well we could make RETFS
always restart (using the PC hack for case 3), and make RETUS
always advance (but then there is no way to restart should some
use be found for that case). The general consensus was why
not just provide for all the cases?]
[ Now some comments of my own.
1. The definitions of the hard-traps and soft-traps both should define
a trap-code which means "no trap" or "no error", this is always
useful.
2. The rules for defaulting or ignoring the modifiers on RETUS or
RETFS are spurious.
-jmb]
∂29-Mar-80 2218 LLW Kudos for Latest GLS FOPpishness
To: "@S1ARCH[DIS,S1]" at SU-AI, RWG at SU-AI, RPG at SU-AI
GLS's proposal below) for addition of a family of four-operand
instructions for the S-1 architecture strikes a peculiarly responsive
chord in me, since it turns out that a symmetric sub-set of operations of
the type which he proposes (e.g., a highly periodic form of ADDFIELDS)
will be extremely useful in certain very important types of DoD real-time
signal processing work. Indeed, it was only because the Mark IIA
implementation could clearly implement such perverted arithmetic (e.g., as
a pair of TOPs) that I had not requested them hitherto--I had intended to
acquire them quietly by making some hapless microcoder a non-refuseable
offer.
However, since GLS has come out of the closet with this proposal, I will
now second it heartily!
Lowell
∂27-Mar-80 0053 GLS at MIT-AI (Guy L. Steele, Jr.) Yet another FOP
Date: 27 MAR 1980 0318-EST
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Yet another FOP
To: s1arch at SU-AI
CC: GLS at MIT-AI, rwg at SU-AI, rpg at SU-AI
Here's another completely random four-operand instruction
for the S-1 not to implement. Recall, for example, that
a relatively good one is BITMERGE: DEST ← (S1 ∧ ¬ S3) ∨ (S2 ∧ S3).
Here we have a cruftier one: ADDFIELDS. S1 and S2 are added
together and placed in DEST, but S3 divides the word up
into fields. Each 1-bit in S3 marks the right-hand bit of a field.
Carries are not to propagate from one field to the next; hence
if S3 is the binary quarter-word 000101101 then four independent
additions occur: one is mod-16, one is mod-4, one mod-2, and one mod-4.
One can model this as saying that a 1-bit in S3 suppresses the carry
into that bit during the addition. If there were a complete set of
such "field-specified" operations, like SUB, MAX, and MIN, one
could do all kinds of wondrous things. Anyway, here are two
encodings of this operator as S-1 instructions (maybe good examples
for the manual?):
[a] Small but slow (iterative):
MOV R0,S1
MOV R1,S2
LOOP: AND RTA,R0,R1
SHF.LF RTA,#1 ;RTA has the set of carries
XOR R0,R1 ;R0 gets sum done without carries
ANDTC R1,RTA,S3 ;R1 gets carries, masked by S3
JMP.NEQ R1,LOOP ;iterate until carries settle down
[b] Big but fixed-time (this is tricky -- remember a field may be 1 bit!):
ANDTC RTA,S1,S3 ;mask off low bits of S1 and S2
ANDTC RTB,S2,S3 ; and add them together (the missing
ADD RTA,RTB ; low bits of each field absorb carries)
AND RTB,S1,S2 ;calculate carries from low bits explicitly
SHF.LF RTB,#1
ANDTC RTB,S3
ADD RTA,RTB ;add in those carries; at most one carry to
ANDTC RTA,S3 ; next field has happened, so flush them
XOR RTB,S1,S2 ;calculate the low bits for each field
AND RTB,S3 ; by XOR and then masking, and save in R1
OR DEST,RTB,RTA ;merge low-bits and all-but-low-bits
Let me know if I blew it.
-- Quux
∂02-Apr-80 1303 MLB via SU-TIP mask-controlled alu fops
To: s1arch at SU-AI, RWG at SU-AI, RPG at SU-AI
I found GLS's ADDFIELDS proposal interesting since I have been considering
implementing a similar facility for some high speed signal processor designs.
My idea is somewhat fancier, but might be of some interest for the S1:
In this design the mask acts somewhat differently than in ADDFIELDS: each
bit of the mask assigns the corresponding bit of the result to either one of
two completely independent ALU operations. The micro instruction specifies what
ALUOP-0 and ALUOP-1 are. This allows such things as selective deposit of a byte
or incrementing one field while decrementing another, as well as adding fields
as in GLS's proposal. (Note that the mask can remain fixed for vector ops etc).
Carries, of course, require some special handling, but there are several
possibilities. For carry in, the ALU codes can specify the source of the
appropriate bit, which can be fed to all corresponding fields. For carry
out (which can indicate field overflow) CARRY-OUT-0 and CARRY-OUT-1 signals
can be provided, which would be the IOR of the carry outs from each field.
A hairier scheme is to employ a special "carry register", which would provide
the carry-ins and would recieve the carry-outs. This register could be
analysed after an operation to identify the overflown fields, or conceivably
shifted or something if one was doing something exotic like adding
interdigitated numbers. This is just a nice feature, though.
One problem I've discovered with this scheme is that ALUs tend to come several
bits to a package, which is sort of a pain since you can't get at the bits.
If one is willing to be a little profligate, or, even better, is designing
in VLSI or some such, then this isn't such a problem.
Since I have no idea what the S1 hardware looks like I can't guess whether
such a scheme would be appropriate for current or projected machines. I
have found that such a facility can greatly reduce the ammount of data-moving
monkey-motions for implementing numerous kinds of useful algorithms, and am
definitely considering employing it in some of my own projects.
∂02-Apr-80 1645 SJC Architecture revision meeting
To: "@S1ARCH[DIS,S1]" at SU-AI
Those interested in reviewing SMA3.CHG[DOC,S1] to accept, reject, favor,
or defer pending proposals should meet at 1400 on Friday, 4 April 80 in
the Palace conference area. Printed copies of the controversial parts of
the file will appear in a stack next to the Palace mailboxes as soon as I
can produce them.--Steve
∂04-Apr-80 1710 JBR XCT, page size
To: s1arch at SU-AI
Two proposals have been tentatively agreed upon. Please send dissenting
opinions in soon.
1) Flush the XCT instruction. This instruction is very difficult to
impliment and has other nasty side effects, such as allowing infinite
XCT chains and making it difficult to determine the pc of the target
instruction. It is also always argued what should be used for the PC
when indexing.
2) Change the page size from 512 to 1024 words. In the Mark IIA
implimentation this will allow the virtual to real translation of the PC
to occur in parallel with the instruction cache access. Together with
certain other non-architecture related changes this will greatly improve
the performance of the processor with respect to right and wrong branches.
Page tables will be 16 instead of 32 words long and the segment bounds
checking scheme will be changed appropriately. The segment size field is
still 5 bits but values range from 4 to 19. The top 19 - size bits are
compared for segment bounds checking.
∂09-Apr-80 0233 OTA updated trap proposal.
To: "@S1ARCH[DIS,S1]" at SU-AI
I have made the changes suggested during the architecture meeting of Friday.
The updated file is in trap.pro[1,ota] on sail. A few comments are in order.
I changed the wording of the description of the RETF/US instruction to try
and explain it a bit better. Comments are welcome. I also discovered that
the gate vector needs and extra field for the maximum vector index which I
added. Also we decided not to make anymore traps be soft instead of hard since
it was decided that it was better to err on the side of the hard traps since
outward simulation is always possible. All the rest of the changes were
simple editing.
∂13-Apr-80 1421 BPM AIDS
To: "@JOB.DIS[1,BPM]" at SU-AI
Friends,
On April 21st I will be joining a new company called Advanced Information
and Decision Systems (or "AIDS" for short). Its charter is to perform
research and development, consulting, and product development in the areas
of artificial intelligence, computer science, decision science, operations
research, control theory, and signal processing. Initially I will be
developing programming environments and other knowledge based
applications. My new business address and telephone number are
Advanced Information and Decision Systems
201 San Antonio Circle, Suite 286
Mountain View, CA 94040
(415) 941-3912
My ARPAnet address remains MCCUNE@USC-ISIE.
Brian McCune
∂24-Apr-80 0705 WORTMAN at USC-ISI Request for U-Code
Date: 24 Apr 1980 0657-PST
From: WORTMAN at USC-ISI
Subject: Request for U-Code
To: rls at SU-AI
cc: Wortman
Dick,
We are still very interested in obtaining any new information
on UCode (last we have is 0.3), and a copy of any
software that processes U-Code.
Any guess when it might be available?
Dave Wortman
Computer Systems Research Group
University of Toronto
Toronto, Ontario
Canada M5S 1A4
-------
∂27-Apr-80 0032 RLS via ACCAT-TIP buglist
To: conway at PARC-MAXC
CC: RLS at SU-AI
Page 87 Last sentence repeated
page 130 last line addressible< addressable
Gillian ackland
Linkabit 10453 roselle st
san diego 92121
=======
Lynn,
Reply directly to Gillian: my account at Stanford is very dormant now.
Books came in the day of the second class, so we are in good shape now.
Thanks a lot for the MIT notes you sent , and for Carlo's notes.
Dick Sites
∂02-May-80 1628 SJC S-1 Architecture Update
To: "@S1ARCH[DIS,S1]" at SU-AI
I have finally revised SMA3.CHG[DOC,S1] to reflect the 4 April 80 meeting.
ACCEPTED:
Gates
Paramaterized traps/interrupts
Revised I/O architecture
ADJBP algorithm
Make DSHF and VDSHF easier to use
New instructions UDIVV, UDIVLV
Redefine NEXT( ) to allow constant operands
Renumber I/O memories
Allow scattered rows in matrix operands
Forbid vector operands in the register space
IOR and IOW instructions
Change I/O mode S to deal with full 36 bit words
VEXCH instruction
How I/O instructions avoid clearing out the cache
REJECTED:
New FOP instructions BITMERGE, ADDFIELDS
Extend instruction-state area (incorporated in "Parameterized traps/interrupts")
Call for solutions to the trace trap problem (incorporated in "Gates")
Privileged bits in PROC_STATUS (obsoleted by "Gates")
MODIFIED but still ACCEPTED:
Context switching
Linkage instructions
ACCESS_MODE definition/eliminate uncached modes
∂07-May-80 1104 JMB RMW Instructions
To: s1arch at SU-AI
There has been some talk for a while that class 0 TOPs (op1 := op1 op op2)
will be done with a read-modify-write interlock on op1. Is this, in fact,
going to be the case? And, should it be defined to act in this way in
SMA-*? It would certainly be useful if this could be guarenteed to be the
case.
∂07-May-80 1153 LCW RMW Instructions
To: "@S1ARCH[DIS,S1]" at SU-AI
∂07-May-80 1104 JMB RMW Instructions
To: s1arch at SU-AI
There has been some talk for a while that class 0 TOPs (op1 := op1 op op2)
will be done with a read-modify-write interlock on op1. Is this, in fact,
going to be the case? And, should it be defined to act in this way in
SMA-*? It would certainly be useful if this could be guarenteed to be the
case.
[Tom and I just discussed this. The Mark IIA is designed to work this
way, even in a multiprocessor configuration. However, we would rather not
commit the architecture at this point, because we need to think about the
implications that such a decision would have on future implementations.
We think the architecture could be committed about the time the Mark IIA
starts to run. Meanwhile, I think that you should count on the feature
with a reasonably high probability. Curt]
∂15-May-80 1543 PEG CHKT & F
To: s1ucode at SU-AI
To: s1ucode at SU-AI
∂12-May-80 2328 CSD.MOGUL at SU-SCORE U-code instructions CHKT, CHKF
Date: 12 May 1980 2325-PDT
From: CSD.MOGUL at SU-SCORE
Subject: U-code instructions CHKT, CHKF
To: pn at SU-AI
cc: peg at SU-AI, csd.broder at SU-SCORE
I might have asked this question before, but I don't think I got an
answer:
In PAIL-6, CHKF (and similarly, CHKT) is described as popping the
boolean from the stack only if the test passes; if this is so, it
causes a great inefficiency, since on the VAX I can test and pop
at the same time; if I have to throw in extra code either to first
test and then pop, or to pop and then patch things up, things get
unpleasant.
Is PAIL-6 correct (or is it just mis-worded)? If so, why not change
it?
-Jeff
-------
1. PN and I could think of no instance where UPAS generates either
CHKT or CHKF. We surmise that these instructions originally came
from the optimizer folks.
2. The only motivation for not popping the stack would be to preserve
the value for debugging purposes. Since the value would be implicit
in the instruction, this argument appears to be weak.
3. In SOPAIPILLA, "popping the stack" has no meaning at runtime anyway.
At compile time, it goes ahead and pops it, obviously, unless the
boolean is a constant and is wrong (in which case the world ends).
4. Therefore, in view of 1, 2, and 3, go ahead and test&pop. PAIL7
will probably clear this up.
-- Phil
∂15-May-80 1613 PEG UPAS and sets
To: s1ucode at SU-AI
SAIL crashed while I was sending this the first time. If you receive
multiple copies, I apologize.
Response to Jeff Mogul's msg:
1. Re: sets. UPAS treats sets as bitstrings; if you want 256-element
sets, UPAS will allocate 256 bits for them (complete with variable
offsets, etc.). If this is what you mean by "pack", then yes, UPAS
packs sets.
2. Re: mailing list. Mail to the pseudo-user S1UCODE@SAIL will get to
all of the interested people (plus a few...). You are on that list.
-- Phil Gerring
∂19-May-80 2206 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 12603
∂04-Jun-80 1420 TM Saturday
To: S1 at SU-AI, WVC at SU-AI
The S-1 Project/O-Group members and friends are all invited to my house
this Saturday, June 7, at 3pm for home made ice cream and dinner to
celebrate completion of my Ph.D. from Stanford.
Come to 5665 Bridgeport Cr., Livermore Ca. Detailed map available upon
request. RSVP appreciated.
Tom
∂16-Jun-80 1213 SJC Segment bounds checking
To: "@S1ARCH[DIS,S1]" at SU-AI
The Mark IIA implementation will check segment bounds on operands fetched
as data but not on operands fetched as instructions. Should we make this
rule a part of the architecture, or say that bounds checking occurs in
both cases but the Mark IIA implementation is incomplete?
∂16-Jun-80 2058 MOON at MIT-MC (David A. Moon) Segment bounds checking
Date: 16 JUN 1980 2359-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: Segment bounds checking
To: SJC at SU-AI
CC: @S1ARCH[DIS,S1] at SU-AI
Date: 16 Jun 1980 1213-PDT
From: Steven Correll <SJC at SU-AI>
Subject: Segment bounds checking
To: "@S1ARCH[DIS,S1]" at SU-AI
The Mark IIA implementation will check segment bounds on operands fetched
as data but not on operands fetched as instructions. Should we make this
rule a part of the architecture, or say that bounds checking occurs in
both cases but the Mark IIA implementation is incomplete?
What are "operands fetched as instructions"? If the XCT instruction
has been flushed, presumably there aren't any. Or if you mean that
PC-relative and indexed branches can branch out of a segment without getting an
error, well, I would say that the architecture should define this to
be an error, but that it is unimportant to enforce the checking
and the Mark II A doesn't bother. (Although, actually, it seems
like it would take no more than a dozen chips and probably less to
make the Mark II A enforce it.)
∂26-Jun-80 0303 LLW Party Call
To: "@S1P[1,LLW]" at SU-AI
This is your first-and-last notice of and formal invitation to the Annual
`O' Program Independence Day Party, Riot and High Celebration, to be
convened at Noon, 5 July, at last year's location (south side of the lake,
just west of the formal parking area, adjacent to the `soccer field') at
Del Valle Regional Park; Cindy at 415-422-7286 will provide directions for
all those who can't remember/never knew this location. Feel free to bring
spouse/special friend, and any children deemed expendable.
Applicable Federal statutes prevent full description of all the activities
and entertainments which will be featured at this gala event, but we can
say that TM will be offering rides to the unwary in his new yacht, and PMF
will be showing off some of the negative-delay wires on which Mark IIA
ABOX operation is predicated. Feel free to bring amusing items of your
own, however.
RSVP to Cindy (CDW@SAIL) or Chris (CEG@SAIL) in a timely fashion, or risk
being undernourished.
Lowell
∂30-Jun-80 1330 SJC Size of address space IDs
To: "@S1ARCH[DIS,S1]" at SU-AI
The architecture devotes an entire singleword to specifying each address
space ID (the number used to make unique the map cache entries for two
processes being swapped into the same address space), but the valid length
of the ID will probably vary from one implementation to the next. Should
we
a. Say that the number of valid bits in an address space ID is
implementation-dependent,
b. Say that the number of valid bits in an address space ID is 27 (or 31
or 36) but the Mark IIA implementation provides only 11,
or
c. Fix the number at 11?
∂07-Jul-80 2115 Daniel L. Weinreb <DLW at MIT-AI> Clearing the map caches
Date: 7 July 1980 23:31-EDT
From: Daniel L. Weinreb <DLW at MIT-AI>
Subject: Clearing the map caches
To: S1ARCH at MIT-AI
The instruction descriptions in my old draft SMA-4 for the instructions
that remove entries from the map caches have two deficiencies. First,
we need an instruction that clears out the entire map cache, in a
microcode loop that goes as fast as possible. Secondly, the existing
instructions do not specify which address space ID the operand address
is taken to refer to; I would like for the address space ID to be an
operand of the instruction, so that I could clear a given address in a
given address space.
∂09-Jul-80 1142 SJC Thanks and fiche
To: "@S1[DIS,S1]" at SU-AI
∂09-Jul-80 1134 SJC Thanks and fiche
To: "@S1[DIS,S1]" at SU-AI
A belated thanks to all who contributed to the infamous greenbook; your
efforts have finally been packed off to the printer's.
I'm creating a file area [FIC,S1] to collect all program sources, data
files, or other material you'd like to put in the microfiche that
accompanies the greenbook. (We'd like to include everything we expect to
give out to the world, so that it's equally available to all readers and
relieves us of the hassle of answering individual requests--but remember
that this is a record of fiscal 1979 work, not of all work to date.) On 16
July 80 I'll take whatever I find there and commit it to plastic, and then
remove the area. Let me know if that date poses any problems, or if
somebody with a likely interest in fiche is unlikely to see this message
by then.
--Steve
∂09-Jul-80 1152 SJC Miscellany
To: "@S1ARCH[DIS,S1]" at SU-AI
Architecture proposals
These proposals arose in the process of reforming SMA4.
Proposed: Location of TRPSLF vectors
The accepted trap scheme lumps soft traps and TRPSLF traps. This
proposal would therefore locate the 64 TRPSLF vectors preceding those
of the soft traps, and thus soft trap n would be the 64+n'th vector
following the origin specified by TDBP and its table of pointers.
Proposed: Gates and execute brackets
The gate mechanism permits you to call a routine located on a page
whose STE.EB or PTE.EB fields would otherwise forbid execution.
(If this were not so, then in the case where the user and executive
share the same address space, it would not be possible to protect
the executive from the user's calls while still allowing gate crossings
into the executive.)
Proposed: New instruction PVALID
PVALID Validate pointer XOP
Validate the pointer OP1 as if it were actually being moved to its
current location from a location in the ring specified by OP2. If OP2
is not within the range 0..3, a hard trap occurs.
Proposed: Long-deferred definition of call tracing
Call tracing uses CALL_TRACE_ENB and CALL_TRACE_PEND bits in
PROCESSOR_STATUS just as instruction tracing does. CALL_TRACE_PEND
is checked at the beginning of an instruction, but after handling
TRACE_PEND, and can cause a trap only if the *preceding* instruction
was one of the following:
CALL
CALLX
RETURN
RETGATE
JSR
RETSR
RET
JCR
JMPCALL
JMPRET
Proposed: Eliminate VINI
VINI is no longer needed since one can use VTRANS to move a constant to
a vector.
∂09-Jul-80 1457 JBR
To: s1arch at SU-AI
VINI is no longer needed since one can use VTRANS to move a constant to
a vector.
[No, you shouldn't eliminate VINI since sometimes you want to initialize
an array to a value that is in a memory location, say, rather than a
constant. Besides, I've already written the microcode. --jeff]
∂09-Jul-80 1504 JMB
To: s1arch at SU-AI
∂09-Jul-80 1152 SJC Miscellany
To: "@S1ARCH[DIS,S1]" at SU-AI
Architecture proposals
Proposed: Gates and execute brackets
The gate mechanism permits you to call a routine located on a page
whose STE.EB or PTE.EB fields would otherwise forbid execution.
[1. I believe that there is no PTE.EB field. 2. This description is
only a side effect of what actually happens. The EB should be checked
on any instruction fetch (by comparision with the ring of the PC); gate
crossings magically change the ring of the PC with the result that the
EB check always success when it should.]
Proposed: New instruction PVALID
PVALID Validate pointer XOP
Validate the pointer OP1 as if it were actually being moved to its
current location from a location in the ring specified by OP2. If OP2
is not within the range 0..3, a hard trap occurs.
[Normal usage would have a pointer being validated against a pointer
addressing the ring from which the 1st pointer is assumed to have
originated. Consequently, it would be more useful if OP2 were in
pointer format. OP1 would be validated against the tag field of OP2.
The validation would proceed as if OP2 was a pointer to OP1, i.e. process
the tag of OP2 to update the validation level (traps are possible if
OP2.tag held a fault tag). Then fetch OP1 and transform its tag and
the validation level in the normal way. Note that the trap if the tag
addressed a ring less than the validation level should occur in both
steps.]
Proposed: Eliminate VINI
VINI is no longer needed since one can use VTRANS to move a constant to
a vector.
[I object. VINI would still be useful to initialize an entire matrix or
array to a variable.]
∂09-Jul-80 1627 MOON at MIT-MC (David A. Moon) JMB's comments on SJC's mail
Date: 9 JUL 1980 1909-EDT
From: MOON at MIT-MC (David A. Moon)
Subject: JMB's comments on SJC's mail
To: s1arch at SU-AI
Jeff's points are all well taken. It is important that the ring number
in the pointer validation instruction not be a constant. VTRANS can
store a scalar variable into a vector by the trick of indexed constant
addressing mode, except that this is unacceptable because it does not
work for double-precision.
∂11-Jul-80 2158 DLW at MIT-AI (Daniel L. Weinreb) RPHYS,WPHYS
Date: 12 JUL 1980 0050-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: RPHYS,WPHYS
To: S1ARCH at MIT-AI
I would like two instructions added to the architecture. Their purpose
is to read or write a singleword identified by its physical address
rather than its virtual address. I know of several uses for such an
instruction in Amber, and it seems useful in general.
I have discused this with JBR; he decided on the instruction formats
that follow based on practicality of implementation (in other words,
the dedicated register is used, rather than using OP2, because it would
be too hard to implement otherwise, so don't complain that it is
inelegant even if it is).
RPHYS XOP
Purpose: R3 holds a physical address. Write the contents of the location
addressed by the physical address in R3 into OP1.
Restrictions: Illegal in user mode.
Exceptions: (I guess this should cause a non-existent memory hard trap
if the physical address does not correspond to configured memory, but
no such fault is listed in SMA-4.)
Precisions: R3 holds a 34-bit physical quarterword address. OP1 is
a singleword.
The WPHYS instruction is the same except that it writes OP1 into the
location addressed by the physical address in R3. This proposal
only uses two opcodes.
∂11-Jul-80 2240 DLW at MIT-AI (Daniel L. Weinreb) More instructions
Date: 12 JUL 1980 0131-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: More instructions
To: S1ARCH at MIT-AI
In addition to the RPHYS and WPHYS instructions, we would also like
physical-memory versions of VIOR and VIOW, to transfer blocks of data
between physical memory and I/O memories. These instructions could be
called VPIOR.{B,Q,H,S} and VPIOW.{B,Q,H,S}. They are the same as
VIOR and VIOW respectively except that RTA holds the physical address of
the first location of the physical memory vector, and OP1 specifies the
vector in the I/O memory. Also, these instructions are illegal in user mode.
The proposal uses eight opcodes.
∂13-Jul-80 0123 DLW at MIT-AI (Daniel L. Weinreb) New instruction: LBITFST
Date: 13 JUL 1980 0412-EDT
From: DLW at MIT-AI (Daniel L. Weinreb)
Subject: New instruction: LBITFST
To: S1ARCH at MIT-AI
I propose addition of a lengthwise vector version of BITFST, to be
called LBITFST (by analogy with LBITCNT). It finds the first bit in a
vector of anywords. This seems quite easy to implement; the ABOX just
keeps passing over words of zeroes until it finds a non-zero word, and
then it does what BITFST would do to that word. This is generally
useful for scanning a large bit map to find the next bit that is "on".
It only takes one opcode.
∂13-Jul-80 1654 JMB Restrict UCMPSF and CMPSF to conserve opcodes
To: s1arch at SU-AI
While proofing SMA4, it occured to me that there is a possible compromise
on the following deferred sma3.chg proposal:
------
UCMPSF and CMPSF will
now become XOP rather than TOP instructions, taking an {RTA,RTB} modifer.
Instruction: CMPSF.{RTA,RTB}.{GTR,EQL,GEQ,LSS,NEQ,LEQ}
Class: XOP
Purpose: RTA←OP1 cond OP2 or RTB←OP1 cond OP2
(While the assembler accepts all six conditions, it
converts {GTR,GEQ} to {LEQ, LSS} by swapping operands)
[It would be POSSIBLE for LISP to generate code with this instruction;
it would just entail rewriting a fair portion of the code generator
for the LISP compiler (the part that compiles predicate tests, etc.,
and the part that does register allocation to know that predicates
may require an RT register). Right now the TOP format is assumed
and used moderately much.--GLS]
------
We could change (U)CMPSF.{LSS.LEQ} to an ROP whose symmetric forms
are replaced by GEQ,GTR forms. This would produce a savings of
32 opcodes.
∂14-Jul-80 1733 GLS at MIT-AI (Guy L. Steele, Jr.) Instruction-of-the-month Club
Date: 14 JUL 1980 2031-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Sent-by: GJS at MIT-AI
Subject: Instruction-of-the-month Club
To: s1arch at SU-AI
I agree with the LBITCNT proposal (I thought that had been
considered a year ago?). Also, how about LBITEX? That would
have to be useful! (Consider what it means as a PASCAL-set
operation.)
∂15-Jul-80 1455 JMB
To: s1arch at SU-AI
Proposed architecture changes. This have been agreed to in principal
by JBR and myself.
Revised ENTRY instruction
Change the entry instruction so that it is not as glaringly dependent on
the Amber calling sequence as currently defined. This should make it more
general, and allow us the luxury of being able to change our minds. The
"stack frame" format is simplified to the following:
SF.ENTRY←DESC ; ptr to 1st instruction/debug hooks
SF.FLAG ; as before
SF.RETURN←ADDR ; as before
Purpose: establish a new stack frame header on the stack. Set OP1 to
ADDRESS (OP2); set NEXT (OP1) to 0; set FP to ADDRESS (OP1).
[There are two changes implicit in this definition. First, the SP is no
longer set by this instruction. Second, instead of saving PC←NEXT←INSTR,
you get to specify the address to be saved. The reason behind both is
that it turns out it is often useful to do various initializations before
the entry instruction. For example, copy Pascal by value record or array
parameters. (This is so that a debugger can say with certainty that the
value of the parameters is valid *once* the stack frame has been created.)
This means that the SP must therefore be advanced first so as to cover the
words processed in initialization. Also, it means that the entry
instruction is no longer the true 1st instruction. The change gives you a
change to specify what it actually is. With this, the Amber entry
sequence would be
L: ALLOC.n+2 CP-n,(SP)4*<n+2+m> ; n = no. parms regs, save CP,FP too
... ; other initializations
ENTRY (SP)-<4*m>,(PC)L-. ]
Revised RET instruction
Purpose: Set SP to ADDRESS (OP2). OP1 contains a pointer giving the
return address; branch to that location.
[The definition of RET in SMA-4 is defective. This fixes it, and also
appears to be what is needed in certain circumstances with the above
change.]
∂16-Jul-80 1122 SJC SMA-4's last stand
To: "@S1ARCH[DIS,S1]" at SU-AI
Anyone willing to look for bugs in the version of SMA-4 distributed
this past Friday is encouraged to do so between now and this coming Friday,
either by borrowing one of the copies floating around the Palace or by
reading SMA4Cn.POX[SM4,S1] (n:=1,2,3) and ignoring the backslashes.
Noting a last gasp of interest in architectural modifications, I propose
a meeting on Friday, 18 July at 1400 in the Palace conference
room to review SMA3.CHG[DOC,S1]. I have added the latest flurry of
proposals to that file, and will endeavor to print copies of them prior
to the meeting.
Comments and corrections are still welcome after Friday, but will
contribute toward SMA-5.
--Steve
∂16-Jul-80 1138 SJC Fiche
To: "@S1[DIS,S1]" at SU-AI
Here are answers to some questions I've received about greenbook microfiche
since my earlier message asking that contributions be placed in [FIC,S1] by
today:
1. Can I submit current files instead of old, buggy ones even if the new
ones include some work done since FY1979?
Yes, particularly if the new ones are more easily accessible.
2. Can I give you pointers to files instead of putting copies on [FIC,S1]?
Yes.
3. How do I tell whether my files belong on fiche?
Perhaps it would help to list the contents of last year's fiche. If you
are responsible for significant modifications to any of last year's
material, or if you are responsible for similar material, you probably
should consider immortalization on Mylar:
FASM.FAI FSIM.FAI SOPAS09.PAS PASRUN.S1
NUMER1.S1 PCPW5.PAS PCFOR0.PAS LINK.PAS
OBS1.S1 OPS.IN OPS.OUT UYK.S1
TEN.S1 DDT.S1 M.PAS SORT.PAS
LOCMAP.PAS R.PAS HINT.PAS ECO.PAS
TRL.PAS WR.PAS BREF.PAS DRW
LAYOUT RTOM DEFS CBLS
IOS MICRO.PAS F.MIC D.S1
P.MIC I.MIC E.MIC EDIAG.S1
MDDT.PAL
∂16-Jul-80 1302 GLS at MIT-AI (Guy L. Steele, Jr.) One more note on that T-field crock
Date: 16 JUL 1980 1526-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: One more note on that T-field crock
To: s1arch at SU-AI
Here's another FORTRAN statement (admittedly not a simple expression)
that you can't execute without any MOV instructions:
C(I+J) = A(K+L) + B(M+N)
This is a simpler and more convincing example, I think, than the old
A = B(I+J) * C(K+L) + D(M+N) * E(P+Q)
The new one looks far more likely to appear in a real program,
perhaps one that mashes triangular matrices or something awful
like that?
Recall that the four index addends on the left of the + in the old
case must be distinct from the four on the right; if not, you
don't need a MOV instruction (I demonstrated that some time ago,
by some rather hairy address arithmetic). I suspect that you can
get away without using MOV if any two index addends not belonging
to the same array are the same, in the new example.
I just thought of another example:
C(I+J) = A(K+L) + P*Q
∂16-Jul-80 1332 GLS at MIT-AI (Guy L. Steele, Jr.) One more note on that T-field crock
Date: 16 JUL 1980 1526-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: One more note on that T-field crock
To: s1arch at SU-AI
Here's another FORTRAN statement (admittedly not a simple expression)
that you can't execute without any MOV instructions:
C(I+J) = A(K+L) + B(M+N)
This is a simpler and more convincing example, I think, than the old
A = B(I+J) * C(K+L) + D(M+N) * E(P+Q)
The new one looks far more likely to appear in a real program,
perhaps one that mashes triangular matrices or something awful
like that?
Recall that the four index addends on the left of the + in the old
case must be distinct from the four on the right; if not, you
don't need a MOV instruction (I demonstrated that some time ago,
by some rather hairy address arithmetic). I suspect that you can
get away without using MOV if any two index addends not belonging
to the same array are the same, in the new example.
I just thought of another example:
C(I+J) = A(K+L) + P*Q
∂16-Jul-80 1336 GLS at MIT-AI (Guy L. Steele, Jr.) One more note on that T-field crock
Date: 16 JUL 1980 1526-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: One more note on that T-field crock
To: s1arch at SU-AI
Here's another FORTRAN statement (admittedly not a simple expression)
that you can't execute without any MOV instructions:
C(I+J) = A(K+L) + B(M+N)
This is a simpler and more convincing example, I think, than the old
A = B(I+J) * C(K+L) + D(M+N) * E(P+Q)
The new one looks far more likely to appear in a real program,
perhaps one that mashes triangular matrices or something awful
like that?
Recall that the four index addends on the left of the + in the old
case must be distinct from the four on the right; if not, you
don't need a MOV instruction (I demonstrated that some time ago,
by some rather hairy address arithmetic). I suspect that you can
get away without using MOV if any two index addends not belonging
to the same array are the same, in the new example.
I just thought of another example:
C(I+J) = A(K+L) + P*Q
∂17-Jul-80 0855 GLS at MIT-AI (Guy L. Steele, Jr.) Code for INN
Date: 17 JUL 1980 1135-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Code for INN
To: s1sopa at SU-AI
CC: s1arch at SU-AI
Other approaches to the INN problem:
(1) Use a byte pointer.
ADJBP.S RTA,[<byte pointer to set, size=1 bit>],I
LDB.S RTA,RTA ;I may not have all the modifiers right
JMPZ.NEQ RTA,TRUE ; I can't find my Green Book today.
JMPA FALSE
Of course, ADJBP uses a division internally, but this gives the processor
a chance to try to optimize in weird ways internally?
(2) Here is an approach for sets up to 320. bits large; that's 8 words plus
32. bits. *** It is assumed that the word preceding the set can be read
without causing an error (but its contents are ignored. ***
QUO2.S RTA,I,#5 ;divide I by 32.
ANDTC.S RTB,I,#37 ;I mod 32, with a twist
SHF.LF.S RTB,RTB,#20
SHF.LF.D RTA,SETADDRESS-1(RTA),OFFSETTABLE(RTA)
SKP.ANY RTA,RTB,TRUE
JMPA FALSE
OFFSETTABLE: 36. ? 32. ? 28. ? 24. ? 20. ? 16. ? 12. ? 8 ? 4 ? 0
This assumes that the bits of a "set" (OH! THOSE PASCAL CRETINS FOR
CONFUSING THE WORLD ON THE DISTINCTION BETWEEN A SET AND A PARTICULAR
WAY OF REPRESENTING ONE!!!) are stored from left to right in a word,
in successively higher-addressed words. The previous solutions seem
to have assumed bits stored from right to left. (The cretinous
bit-numbering problem strikes again. The difficulty is that
the bit numbering in a doubleword is not consistent with that of two
consecutive singlewords, because the hardware puts the less significant
word of a double-word in the higher address. Feh.)
The idea is to approximate a division by 36. (hard) by using a division
by 32. (easy) instead, and then patching it up. So you fetch TWO words
indicated by the quotient by 32. which together contain the 32-bit
chunk of interest. Shifting by the element of OFFSETTABLE (which is
obviously used purely to avoid more instructions) causes that 32-bit
chunk to be left-justified in a word. Then you just test the relevant bit.
The second and third instructions could have been
AND.S RTB,I,#37
SHF.RT.S RTB,#MINNUM,I
but that would take a whole constant word to hold MINNUM; the sequence shown
sort of takes the five-bit one's-complement of the remainder mod 32,
and then shifts left a constant 20 octal which can be a short operand.
[By the way, I think previous notes in this series have gotten the operands
to SHF backwards? Isn't S2 the shift count, and S1 the shiftee?]
This technique avoids the division, and also avoids an interlock by putting
two instructions between generation of the quotient and its use as an index.
If division is really that slow, this technique may be suitable
for set sizes greater than 72. and not greater than 320.
Another alternative is:
QUO2.S RTA,I,#5 ;divide I by 32.
AND.S RTB,I,#37 ;I mod 32
SHF.LF.D RTA,SETADDRESS-1(RTA),OFFSETTABLE(RTA)
SHF.LF.S RTA,RTB
JMPZ.LSS RTA,TRUE
JMPA FALSE
This has only one instruction between the quotient and the indexing,
but lets you have a jump instead of a skip. It shifts the bit of
interest up into the sign bit of RTA.
(3) If INN is used very often, maybe there should be an S-1 instruction
to do it quickly?
∂17-Jul-80 2238 CBF Code for INN
To: s1sopa at SU-AI
CC: s1arch at SU-AI
∂17-Jul-80 0855 GLS at MIT-AI (Guy L. Steele, Jr.) Code for INN
Date: 17 JUL 1980 1135-EDT
From: GLS at MIT-AI (Guy L. Steele, Jr.)
Subject: Code for INN
To: s1sopa at SU-AI
CC: s1arch at SU-AI
(2) Here is an approach for sets up to 320. bits large; that's 8 words plus
32. bits. *** It is assumed that the word preceding the set can be read
without causing an error (but its contents are ignored. ***
QUO2.S RTA,I,#5 ;divide I by 32.
ANDTC.S RTB,I,#37 ;I mod 32, with a twist
SHF.LF.S RTB,RTB,#20
SHF.LF.D RTA,SETADDRESS-1(RTA),OFFSETTABLE(RTA)
SKP.ANY RTA,RTB,TRUE
JMPA FALSE
OFFSETTABLE: 36. ? 32. ? 28. ? 24. ? 20. ? 16. ? 12. ? 8 ? 4 ? 0
[Small bug: you mean ANDCT.S not ANDTC.S, but I love it anyway.
However, I think the ADJBP solution is probably the right one for the
general case. Let the hardware figure out the fastest way to do a
divide by 36. Does it Mike?
-CBF]
∂18-Jul-80 1019 SJC SMA3.CHG review meeting
To: "@S1ARCH[DIS,S1]" at SU-AI
Having heard the plaints of those who cannot possibly read SMA4 by
this afternoon, I will accede to pospone the meeting from 1400 today
to 1400 Wednesday, 23 July 80.--Steve
∂22-Jul-80 1402 JJK Auditron
To: S1 at SU-AI, "@KBMS.DIS[THE,JJK]" at SU-AI
We seem to be missing the S1/KBMS auditron from Jayne Pickering's office.
Does anyone know where it is?
∂22-Jul-80 2015 OTA change the name of the PVALID instruction?
To: "@S1ARCH[DIS,S1]" at SU-AI
I would like to suggest that the name of the PVALID instruction be changed to
VALIDP. This makes it more similar to MOVP and also better abbreviates
VALIDate Pointer.
∂23-Jul-80 1018 JJK auditron found!
To: S1 at SU-AI, "@KBMS.DIS[THE,JJK]" at SU-AI
Susan Hill found the auditron in the xerox room where someone [??] had
left it.
∂23-Jul-80 1329 SJC Proposals
To: "@S1ARCH[DIS,S1]" at SU-AI
Various people made the following proposals to me after reading SMA4:
Proposed: Make MOVHWR unprivileged
Proposed: Make TRPSLF parameter format more consistent
When TRPSLF (or TRPEXE) pushes an operand onto the stack within
the parameter area, always zero-extend and right-justify it within
the appropriate doubleword.
∂23-Jul-80 2103 SJC Meeting results
To: "@S1ARCH[DIS,S1]" at SU-AI
SMA3.CHG has been updated to reflect the results of the 23 July 80
meeting. The following proposals were accepted:
Make MOVHWR unprivileged
New instruction PVALID (incorporates:
``Change the name of the PVALID instruction to VALIDP'')
Length of address space IDs
New lengthwise bit instructions
New instructions to address memory physically
Long-deferred definition of call tracing
The following proposals were substantially modified and accepted:
Location of TRPSLF vectors
Generalize the ENTRY instruction, fix RET, rename RETURN to UNCALL
Compromise on restricting UCMPSF and CMPSF to conserve opcodes
Ability to sweep entire map cache
The following proposals were deferred:
New instruction MOVIF and other IF/THEN/ELSEs
Compact interprocessor communication
Details about performance counters
Further restrictions on CMPSF to conserve opcodes
The following reduced to correcting a typo in SMA4:
Make TRPSLF parameter format more consistent
∂06-Aug-80 1647 SJC
To: "@S1ARCH[DIS,S1]" at SU-AI
Proposed: Move TRACE bits to USER_STATUS
Because the bits which manage instruction and call tracing lie
within PROCESSOR_STATUS, it is impossible to disable tracing for
the duration of a soft trap handler and reenable it on returning
to the normal sequence of user instructions.
Moving these bits to USER_STATUS would solve the problem, but
require any instruction capable of altering those bits to flush
the pipe, reducing performance.
Please comment ASAP if you have strong feelings.
∂22-Aug-80 0140 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 14216
∂29-Aug-80 1710 DES
Dick,
I'm not sure if you remember me from you're Stanford days, but
I'll be leaving this Sunday to start (assistant) professing at Columbia,
and wanted to let you know my new address and phone data:
HOME: 560 Riverside Drive, Apt. 11-B
New York, New York 10027
(212) 222-1442 (tentative; to be installed Tuesday, 9/2/80)
SCHOOL: Department of Computer Science
Seeley W. Mudd Building
Columbia University
New York, New York 10027
(212) 280-2736 (general departmental number; no office number yet)
ARPANET: DES@SU-AI (at least until further notice)
Be sure to let me know when you're next in New York; I'd like to stay in
touch. Also, I'd be grateful if you'd let me know of any brilliant
potential graduate students (especially those who might have or develop an
interest in database machines) and/or faculty members who might enjoy
living in the big city.
Regards,
David
∂30-Aug-80 0152 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 14185
The disk allocations have recently been converted to a new accounting
system. If your allocation is not now what you expected it to be,
mail your questions or complaints to DPB.
∂16-Sep-80 1031 justin at SU-ISL nussbaum
Date: 15 Sep 1980 at 0955-PDT
From: justin at SU-ISL
Subject: nussbaum
To: rls at sail
mussbaum
-------
∂23-Sep-80 0345 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 13302
The disk allocations have recently been converted to a new accounting
system. If your allocation is not now what you expected it to be,
mail your questions or complaints to DPB.
∂03-Oct-80 1620 PN phones
To: S1 at SU-AI
Everyone associated with the S-1 project, please add or update
your phone and address in PHON[DOC,S1].
Thanks,
peter
∂04-Oct-80 1555 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 13414
The disk allocations have recently been converted to a new accounting
system. If your allocation is not now what you expected it to be,
mail your questions or complaints to DPB. This may be your last chance!
∂07-Oct-80 1808 Purger
To: S1 at SU-AI
You have exceeded your disk quota.
The files listed below are being purged to reduce your disk
usage to your quota of 9000
Before purging, your files occupied 11579
The disk allocations have recently been converted to a new accounting
system. If your allocation is not now what you expected it to be,
mail your questions or complaints to DPB. This may be your last chance!
PSTAT.DMP[DMP, S1]
PCPE04.DMP[DMP, S1]
UFORT1.DMP[DMP, S1]
UINT.DMP[DMP, S1]
SUPN05.DMP[DMP, S1]
SOPZ22.DMP[DMP, S1]
UPAOLD.DMP[DMP, S1]
UPASS.DMP[DMP, S1]
PCPG11.DMP[DMP, S1]
UPAS0.DMP[DMP, S1]
SUPS07.DMP[DMP, S1]
LOPT.DMP[DMP, S1]
UFORT2.DMP[DMP, S1]
SUPW08.DMP[DMP, S1]
SOPZ22.PAS[SOP, S1]
COMP.DO[SOP, S1]
S1WD22.FAI[SOP, S1]
S1WD22.LDI[SOP, S1]
S1WD22.S1[SOP, S1]
S1WD22.REL[SOP, S1]
SOPZ12.PAS[SOP, S1]
SUPW08.REL[SOP, S1]
SUPW08.LOG[SOP, S1]
SUPG06.PAS[SOP, S1]
REGS[SOP, S1]
SUPS07.PAS[SOP, S1]
SUPN05.PAS[SOP, S1]
BUG.PAS[SOP, S1]
WCOMP.DO[SOP, S1]
SUPW08.PAS[SOP, S1]
PCPG11.PAS[PCP, S1]
Q1.UCO[FOR, S1]
Q2.UCO[FOR, S1]
Q2.PAS[FOR, S1]
Q1.PAS[FOR, S1]
SOPB1A.FOR[FOR, S1]
HB.DO[FOR, S1]
FF2ERR[FOR, S1]
EXAMHB.PAS[FOR, S1]
FF2TLR.RQR[FOR, S1]
FF2.PUB[FOR, S1]
FF2HDR.RQR[FOR, S1]
P1.PAS[FOR, S1]
TITLE.FF2[FOR, S1]
R2.PAS[FOR, S1]
UFORT1.PAS[FOR, S1]
CSA5.TAP[FOR, S1]
R1.PAS[FOR, S1]
CSA4.TAP[FOR, S1]
CSA2.FOR[FOR, S1]
CSA3.INP[FOR, S1]
CSA3.FOR[FOR, S1]
CSA5.FOR[FOR, S1]
HBS1.9[FOR, S1]
HBS1.2[FOR, S1]
HBS1.FOR[FOR, S1]
FSIM.DO[FOR, S1]
Q2FIX.PAS[FOR, S1]
CSA4.6[FOR, S1]
CSA4.7[FOR, S1]
CSA58.FOR[FOR, S1]
TMARK[FOR, S1]
PFTP.DO[FOR, S1]
SIGN.PS1[FOR, S1]
SIGN.UCO[FOR, S1]
SIGN.LDI[FOR, S1]
NBS.NOT[FOR, S1]
T.LDI[FOR, S1]
T.PS1[FOR, S1]
O8A.PS1[FOR, S1]
O8A.FOR[FOR, S1]
O8A.UCO[FOR, S1]
PAS2.DO[FOR, S1]
O8A.LDI[FOR, S1]
TR.UCO[FOR, S1]
TR.LDI[FOR, S1]
SOPU.DO[FOR, S1]
TR.FOR[FOR, S1]
TR.PS1[FOR, S1]
LOPT.DO[FOR, S1]
LOPT.PAS[FOR, S1]
SOPA.DO[FOR, S1]
FUSE.DO[FOR, S1]
PFSE.DO[FOR, S1]
OPT.DO[FOR, S1]
RQR.FF2[FOR, S1]
UFORT2.REL[FOR, S1]
TR.OCO[FOR, S1]
CSA41.INP[FOR, S1]
TR0.LDI[FOR, S1]
DIM.LST[FOR, S1]
DIM.ERR[FOR, S1]
CSA4.FOR[FOR, S1]
SIGN.FOR[FOR, S1]
DIM.UCO[FOR, S1]
CSA4.INP[FOR, S1]
PUCO.PAS[FOR, S1]
DIM.OUT[FOR, S1]
CSA59.FOR[FOR, S1]
T.LST[FOR, S1]
BODY.FF2[FOR, S1]
DIM.LDI[FOR, S1]
TR0.UCO[FOR, S1]
CSA4.LST[FOR, S1]
UFORT2.LOG[FOR, S1]
TR0.PS1[FOR, S1]
DIM.FOR[FOR, S1]
CSA4.8[FOR, S1]
SIGN.OUT[FOR, S1]
T.PAS[FOR, S1]
UFORT2.PAS[FOR, S1]
FOR.DO[FOR, S1]
PUCO.DO[FOR, S1]
DIM.PS1[FOR, S1]
PUCO.DMP[FOR, S1]
WCOMP.DO[FOR, S1]
CSA59.LST[FOR, S1]
T.OUT[FOR, S1]
T.UCO[FOR, S1]
DOC.4[DOC, S1]
GSGSLD.PUB[DOC, S1]
BODY.CS2[DOC, S1]
PASSIX.LDI[LIB, S1]
TEST.LDI[LNK, S1]
LINKS1.PAS[LNK, S1]
CAB[LOG, S1]
LINK[LOG, S1]
OS[LOG, S1]
UYK[LOG, S1]
OS0[LOG, S1]
NUMER[LOG, S1]
TASKS[LOG, S1]
PERF[LOG, S1]
PRINT.FAS[NIL, S1]
OPSV4.FAS[NIL, S1]
STRING.FAS[NIL, S1]
INTERP.FAS[NIL, S1]
REV.FAS[NIL, S1]
DECOMP.FAS[NIL, S1]
FILE.FAS[NIL, S1]
DEMON.FAS[NIL, S1]
FASLOA.FAS[NIL, S1]
CLOAD.FAS[NIL, S1]
LENGTH.LSP[NIL, S1]
HANOID.LSP[NIL, S1]
HANOI2.DO[NIL, S1]
OPSOLD.PAS[OPS, S1]
OPSV4.SOP[OPS, S1]
OPSMK1.SYM[OPS, S1]
OPSV4.SYM[OPS, S1]
OPSMK1.SOP[OPS, S1]
OPSMK1.UYK[OPS, S1]
∂13-Oct-80 1057 WES Disk space
To: S1 at SU-AI
I have transfered most of the large log files (which hadn't been accessed
in a while), and several ufds (which also hadn't been used in a while) on
to the s1 udps. This brought us under allocation by about 500,000 words. In
the next few days it would be good if everyone would trim out the space they
aren`t using, either by deleting outdated files, or by saving them on a udp.
wes
∂13-Oct-80 1551 PTZ log file deletions
To: WES at SU-AI
CC: S1 at SU-AI
Wes -
It's absolutely ESSENTIAL to have at least the log portions of log files
online. Old messages (messages that are at least 6 months or 1 year old) can
be placed on UDPs, but SOPA[LOG,S1] really needs to be instantly available
when you want to find the trail of some change, bug, etc. Probably other S1
project members feel similarly about log files for their subproject. UDP
drives are not available enough for this sort of quick reference (and those
who work in Livermore have the additional problem of finding someone to mount
the UDP even if there is a free drive). COPY can be used to copy only certain
page ranges for easy deletion of old messages. Of course it would be better
(but maybe not worth the trouble) to go through and keep those old pages that
discuss still pending or unresolved issues. I realize that you were saving
the project's skin, disk allocation-wise, but documentation is as important as
the sources. It would be nice if each subproject could manage to police its
own areas, but in reality we seem to need somebody to make sure that it gets
done (no, I'm not volunteering). I am not necessarily saying that you should
put the log files back yourself, but don't be surprised if they show up again,
and please don't just delete them again if they do. The policy should be for
them to be online.
Polle
∂14-Oct-80 1106 WES Log files
To: S1 at SU-AI
I see your point. However, before I can restore the log files, I need
suggestions as to what we absolutely need on line and what we can put on
the UPDs. As of now, if I restore the log files, we are over allocation
again, a situation which I promised Marty Frost we would avoid. If you have
files which can be put on the udps, send me mail and I will put them there
for you. (this is not noble, just an unpopular job). For now, I will restore
as many log files (including sopa) as I can, until I can get some feedback from
everybody. Sorry for the hassle.
wes
∂20-Oct-80 0826 WES Quota
To: S1 at SU-AI
We are over our quota again...
∂21-Oct-80 1301 GLS via CMU-10A [NIL,S1]
To: S1 at SU-AI
I need access to the files that used to be on the directory [NIL,S1].
Could someone please put them on-line again for me?
∂25-Oct-80 1459 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 10513
∂05-Nov-80 1757 JMB
To: "@S1ARCH[DIS,S1]" at SU-AI
MOVIF
I have been considering what code to generate for various high level
operations (particularly string instructions). In the process, I have
come to the conclusion that a MOVIF instruction would be very, very
useful. After looking over the deferred proposals, I would like to
make the following proposal which I believe includes the features of
most of the existing proposals.
MOVIF.{RTA,RTB}.{Q,H,S,D}
Class: TOP, 32 opcodes
If {rta,rtb} <> 0 then dest := s2 else dest := s1.
Normally, you would preceed the instruction with a CMPSF to test the
condition. Most of the TOP forms are useful. In particular, the case
of dest = op1, s1 = op1 and s2 = op2 is DLW's original proposal.
-------
Deferred: New instruction MOVIF
MOVIF.{RTA,RTB}.{T,F}
Class: XOP Move if true
Purpose: IF {RTA,RTB} <> 0 THEN OP1←OP2. A compiler can use this to emit
branchless code for a variety of IF statements of the form "IF <cond> THEN
<lvalue> := <rvalue>". First evaluate the
condition and store in RTA or RTB; then store the rvalue of the assignment
in OP2 and execute MOVIF with the lvalue as OP1.--DLW
[I might suggest a TOP SELECT: DEST_if DEST=0 then S2 else S1.
Note that the T=0 case is useful. Alternatively, an XOP:
ONEOF{RTA,RTB}: {RTA,RTB}_if {RTA,RTB}=0 then OP2 else OP1.
The real problem, of course, is that these are all special cases
of a four-operand instruction: DEST_if S1 then S2 else S3. Sigh.--GLS]
[I kind of like the top format one. -jmb]
[I would not accept this as a counter-proposal, but only as an
additional proposal, because your new instructions do not handle the
basic case that MOVIF is designed to address. The point of MOVIF
is to allow code sequences such as
if a = b then c := d;
or
if a > b then c := d;
or
(if (bit-test 4 a) (setq c d))
to be expressed without the use of a skip or a jump,
to save on wrong-branches.--DLW]
[When did the S1 instructions start fetching DEST to condition operations?
There are 69E105 good things you could do with that, since it gives you
TRUE three operand instructions. (Of course it implies you probably
should rethink most of the instruction set.)
For example you could make SELECT operate bitwise. (I favor the use of S2
as the "conditioning" operand.) Thus,
DEST[k]:=if S2[k]=0 then DEST[k] else S1[k],
would provide for GLS's SELECT or DLW's MOVIF when preceeded by a CMPSF,
and would be a kind of "write under mask" otherwise.
Almost any operation can be usefully generalized to work under a mask/select
scheme. For example adding a constant to a random field without having to
worry about it carrying out into an adjacent field, etc etc etc.
Maybe on the S-2...--MLB]
∂05-Nov-80 2235 JBR MOVIF
To: "@S1ARCH[DIS,S1]" at SU-AI
This instruction sounds useful and easy to implement. Let's change the
name to SELECT, though.
--jeff
∂12-Nov-80 0728 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 11038
∂26-Nov-80 0118 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 10775
∂03-Dec-80 1829 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 11052
∂22-Dec-80 1520 Purger
To: S1 at SU-AI
You are exceeding your disk quota.
Files that occupy space beyond your quota are subject to purging.
If you don't delete some of your files, the purger will.
Your disk quota is: 9000
Your files occupy 10522